Re: [linux-sunxi] Current u-boot crashes my cubietruck!
On 03/29/2014 05:37 PM, Ian Campbell wrote: On Sat, 2014-03-29 at 16:52 +0100, Olliver Schinagl wrote: Hey all, I was using current head on my Cubietruck; and it kept crashing. I first tried to revert the density/width only, but that made no difference what so ever. Oh dear. Aye! Using the merge tag seems to be fine however, d2a8c8da1. So it is one of the newer patches, will slowly progress the line, as time permits, to find the culprit. The first crash I had on cloning git during 3.4.79+; i first reverted to Hans's 3.4 series from fedora 19, but then a big huge oops happened even during boot. And consistently during boot. It doesn't seem to be power relate either. I have since reverted to d9aa5dd3d and that seems to be stable again. Which branch are you running? u-boot-sunxi/sunxi I guess but you mention Hans' series so maybe jwrdegoede/sunxi-next? for u-boot, the linux-sunxi u-boot variant. for the kernel, hans's 3.4 that comes with fedora 19; but I initially experienced these problems with one the sunxi nightlies, a 3.4.79+ I will cook dinner now, and keep the board running using the d9 hash and checkout a few newer revisions then. Stable for 10 minutes now though ;) The obvious first one to try would be d2a8c8da1c6 Merge tag 'v2014.04-rc2' into sunxi. Its immediate parent on the sunxi side is d9aa5dd3d which you've already found to be stable. If you can rule that out then the rest should be fairly tractable to bisect... Looking at gitk d9aa5dd3d...u-boot-sunxi/sunxi --not origin/master most of them are supposed to be no semantic change type cleanups or things which don't touch cubietruck... If it does turn out to be the merge then I think it will be time to take a fine toothed comb to the merge... Luckily, this does not seem the case. I will keep you all posted. Olliver Ian. -- You received this message because you are subscribed to the Google Groups linux-sunxi group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [linux-sunxi] Current u-boot crashes my cubietruck!
On 03/30/2014 12:25 PM, Olliver Schinagl wrote: Status update: d2a8c8d Merge tag 'v2014.04-rc2' into sunxi seems stable and was able to compile u-boot on itself ;) linux-sunxi kept failing due to remote hung endpoints while fetching the full git tree, nothing unexpected there. 4362605 Merge remote-tracking branch 'remotes/ijc/sunxi-merge-v2014.04-rc2' into sunxi So far, that looks good; running a tar xJvf on the linux-sunxi tar.xz causes no issues yet. I'll keep using that rev for a few hours then go onto the next one. I shouted too early :( [ 508.891546] Process login (pid: 2265, stack limit = 0xee5f82f0) [ 508.901743] Stack: (0xee5f9e78 to 0xee5fa000) [ 508.910451] 9e60: 01f9 c006bab0 [ 508.923123] 9e80: d1015788 ee825a78 b7caf08b 0003 ee825a8c c0782b28 d1015788 ee5f9f10 [ 508.935835] 9ea0: 0001 c00d5498 ee5f9f10 0001 ee5f8010 c051a038 c012bc38 [ 508.948540] 9ec0: ee6398b8 ee639800 ee58cb40 271ae921 ee639800 ee63989c [ 508.961336] 9ee0: 0001 ee63990c ee58cb40 c0292cbc 0007 c05442e4 c0292504 c077f97c [ 508.974074] 9f00: ee5f8000 ee5c72c0 0001 ee639800 ee5f8000 ee5f8028 ee5f8000 [ 508.986932] 9f20: 0005 c02935c0 ee825a40 0001 ee5f8000 c000e108 c003d5b8 [ 508.999755] 9f40: b6d3c000 ee5038fc ee4f9884 c0101d18 ee4f9880 ee5038f0 c023b764 [ 509.012692] 9f60: ee4f98b8 eeb9d080 ee5f8000 00f8 c000e108 ee5f8000 [ 509.025742] 9f80: 0005 c003db38 0006efae b6f4 b6f4 00f8 c003dbc4 [ 509.038900] 9fa0: c000df00 0006efae b6f4 0006ef9a b6fbc4c0 [ 509.052039] 9fc0: 0006efae b6f4 b6f4 00f8 00857898 008513f8 000171d8 0005 [ 509.065171] 9fe0: 00f8 be9a7834 b6f0a0f3 b6eaef96 6030 [ 509.078413] [c0299810] (tty_ldisc_hangup+0x3c/0x2a4) from [c0292cbc] (__tty_hangup+0x124/0x378) [ 509.097651] [c0292cbc] (__tty_hangup+0x124/0x378) from [c02935c0] (disassociate_ctty+0x7c/0x240) [ 509.117536] [c02935c0] (disassociate_ctty+0x7c/0x240) from [c003d5b8] (do_exit+0x294/0x784) [ 509.131797] [c003d5b8] (do_exit+0x294/0x784) from [c003db38] (do_group_exit+0x54/0xc8) [ 509.145622] [c003db38] (do_group_exit+0x54/0xc8) from [c003dbc4] (__wake_up_parent+0x0/0x20) [ 509.159980] Code: e2066002 e2505000 0a18 e5953000 (e5933018) [ 509.171733] ---[ end trace 0b4cd254dfcafc0c ]--- [ 509.181906] Fixing recursive fault but reboot is needed! Going back to the parent rev, d3686aa sunxi: use a 4MB malloc pool and report then :) olliver On 03/30/2014 11:05 AM, Olliver Schinagl wrote: On 03/29/2014 05:37 PM, Ian Campbell wrote: On Sat, 2014-03-29 at 16:52 +0100, Olliver Schinagl wrote: Hey all, I was using current head on my Cubietruck; and it kept crashing. I first tried to revert the density/width only, but that made no difference what so ever. Oh dear. Aye! Using the merge tag seems to be fine however, d2a8c8da1. So it is one of the newer patches, will slowly progress the line, as time permits, to find the culprit. The first crash I had on cloning git during 3.4.79+; i first reverted to Hans's 3.4 series from fedora 19, but then a big huge oops happened even during boot. And consistently during boot. It doesn't seem to be power relate either. I have since reverted to d9aa5dd3d and that seems to be stable again. Which branch are you running? u-boot-sunxi/sunxi I guess but you mention Hans' series so maybe jwrdegoede/sunxi-next? for u-boot, the linux-sunxi u-boot variant. for the kernel, hans's 3.4 that comes with fedora 19; but I initially experienced these problems with one the sunxi nightlies, a 3.4.79+ I will cook dinner now, and keep the board running using the d9 hash and checkout a few newer revisions then. Stable for 10 minutes now though ;) The obvious first one to try would be d2a8c8da1c6 Merge tag 'v2014.04-rc2' into sunxi. Its immediate parent on the sunxi side is d9aa5dd3d which you've already found to be stable. If you can rule that out then the rest should be fairly tractable to bisect... Looking at gitk d9aa5dd3d...u-boot-sunxi/sunxi --not origin/master most of them are supposed to be no semantic change type cleanups or things which don't touch cubietruck... If it does turn out to be the merge then I think it will be time to take a fine toothed comb to the merge... Luckily, this does not seem the case. I will keep you all posted. Olliver Ian. -- You received this message because you are subscribed to the Google Groups linux-sunxi group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [linux-sunxi] Current u-boot crashes my cubietruck!
On 03/30/2014 12:33 PM, Olliver Schinagl wrote: On 03/30/2014 12:25 PM, Olliver Schinagl wrote: Status update: d2a8c8d Merge tag 'v2014.04-rc2' into sunxi seems stable and was able to compile u-boot on itself ;) linux-sunxi kept failing due to remote hung endpoints while fetching the full git tree, nothing unexpected there. 4362605 Merge remote-tracking branch 'remotes/ijc/sunxi-merge-v2014.04-rc2' into sunxi So far, that looks good; running a tar xJvf on the linux-sunxi tar.xz causes no issues yet. I'll keep using that rev for a few hours then go onto the next one. I shouted too early :( [ 508.891546] Process login (pid: 2265, stack limit = 0xee5f82f0) [ 508.901743] Stack: (0xee5f9e78 to 0xee5fa000) [ 508.910451] 9e60: 01f9 c006bab0 [ 508.923123] 9e80: d1015788 ee825a78 b7caf08b 0003 ee825a8c c0782b28 d1015788 ee5f9f10 [ 508.935835] 9ea0: 0001 c00d5498 ee5f9f10 0001 ee5f8010 c051a038 c012bc38 [ 508.948540] 9ec0: ee6398b8 ee639800 ee58cb40 271ae921 ee639800 ee63989c [ 508.961336] 9ee0: 0001 ee63990c ee58cb40 c0292cbc 0007 c05442e4 c0292504 c077f97c [ 508.974074] 9f00: ee5f8000 ee5c72c0 0001 ee639800 ee5f8000 ee5f8028 ee5f8000 [ 508.986932] 9f20: 0005 c02935c0 ee825a40 0001 ee5f8000 c000e108 c003d5b8 [ 508.999755] 9f40: b6d3c000 ee5038fc ee4f9884 c0101d18 ee4f9880 ee5038f0 c023b764 [ 509.012692] 9f60: ee4f98b8 eeb9d080 ee5f8000 00f8 c000e108 ee5f8000 [ 509.025742] 9f80: 0005 c003db38 0006efae b6f4 b6f4 00f8 c003dbc4 [ 509.038900] 9fa0: c000df00 0006efae b6f4 0006ef9a b6fbc4c0 [ 509.052039] 9fc0: 0006efae b6f4 b6f4 00f8 00857898 008513f8 000171d8 0005 [ 509.065171] 9fe0: 00f8 be9a7834 b6f0a0f3 b6eaef96 6030 [ 509.078413] [c0299810] (tty_ldisc_hangup+0x3c/0x2a4) from [c0292cbc] (__tty_hangup+0x124/0x378) [ 509.097651] [c0292cbc] (__tty_hangup+0x124/0x378) from [c02935c0] (disassociate_ctty+0x7c/0x240) [ 509.117536] [c02935c0] (disassociate_ctty+0x7c/0x240) from [c003d5b8] (do_exit+0x294/0x784) [ 509.131797] [c003d5b8] (do_exit+0x294/0x784) from [c003db38] (do_group_exit+0x54/0xc8) [ 509.145622] [c003db38] (do_group_exit+0x54/0xc8) from [c003dbc4] (__wake_up_parent+0x0/0x20) [ 509.159980] Code: e2066002 e2505000 0a18 e5953000 (e5933018) [ 509.171733] ---[ end trace 0b4cd254dfcafc0c ]--- [ 509.181906] Fixing recursive fault but reboot is needed! Going back to the parent rev, d3686aa sunxi: use a 4MB malloc pool and report then :) Right, this one doesn't seem to crash; but I cant extract the .xz either... linux-sunxi/.git/objects/pack/pack-06962d550c8aab83282655647120ce3552ca5b0e.idx xz: (stdin): Compressed data is corrupt tar: Unexpected EOF in archive tar: Unexpected EOF in archive tar: Error is not recoverable: exiting now and that constantly, sometimes it gets to go 1 file further ... ironically the sha1 calculation worked fine I'll go back to pre-merge and double check that. olliver On 03/30/2014 11:05 AM, Olliver Schinagl wrote: On 03/29/2014 05:37 PM, Ian Campbell wrote: On Sat, 2014-03-29 at 16:52 +0100, Olliver Schinagl wrote: Hey all, I was using current head on my Cubietruck; and it kept crashing. I first tried to revert the density/width only, but that made no difference what so ever. Oh dear. Aye! Using the merge tag seems to be fine however, d2a8c8da1. So it is one of the newer patches, will slowly progress the line, as time permits, to find the culprit. The first crash I had on cloning git during 3.4.79+; i first reverted to Hans's 3.4 series from fedora 19, but then a big huge oops happened even during boot. And consistently during boot. It doesn't seem to be power relate either. I have since reverted to d9aa5dd3d and that seems to be stable again. Which branch are you running? u-boot-sunxi/sunxi I guess but you mention Hans' series so maybe jwrdegoede/sunxi-next? for u-boot, the linux-sunxi u-boot variant. for the kernel, hans's 3.4 that comes with fedora 19; but I initially experienced these problems with one the sunxi nightlies, a 3.4.79+ I will cook dinner now, and keep the board running using the d9 hash and checkout a few newer revisions then. Stable for 10 minutes now though ;) The obvious first one to try would be d2a8c8da1c6 Merge tag 'v2014.04-rc2' into sunxi. Its immediate parent on the sunxi side is d9aa5dd3d which you've already found to be stable. If you can rule that out then the rest should be fairly tractable to bisect... Looking at gitk d9aa5dd3d...u-boot-sunxi/sunxi --not origin/master most of them are supposed to be no semantic change type cleanups or things which don't touch cubietruck... If it does turn out to be the merge then I think it will be time to take a fine toothed comb to the merge... Luckily, this does not seem the case. I will keep you all posted. Olliver Ian.
Re: [linux-sunxi] Current u-boot crashes my cubietruck!
On 03/30/2014 12:43 PM, Olliver Schinagl wrote: On 03/30/2014 12:33 PM, Olliver Schinagl wrote: On 03/30/2014 12:25 PM, Olliver Schinagl wrote: Status update: d2a8c8d Merge tag 'v2014.04-rc2' into sunxi seems stable and was able to compile u-boot on itself ;) linux-sunxi kept failing due to remote hung endpoints while fetching the full git tree, nothing unexpected there. 4362605 Merge remote-tracking branch 'remotes/ijc/sunxi-merge-v2014.04-rc2' into sunxi So far, that looks good; running a tar xJvf on the linux-sunxi tar.xz causes no issues yet. I'll keep using that rev for a few hours then go onto the next one. I shouted too early :( [ 508.891546] Process login (pid: 2265, stack limit = 0xee5f82f0) [ 508.901743] Stack: (0xee5f9e78 to 0xee5fa000) [ 508.910451] 9e60: 01f9 c006bab0 [ 508.923123] 9e80: d1015788 ee825a78 b7caf08b 0003 ee825a8c c0782b28 d1015788 ee5f9f10 [ 508.935835] 9ea0: 0001 c00d5498 ee5f9f10 0001 ee5f8010 c051a038 c012bc38 [ 508.948540] 9ec0: ee6398b8 ee639800 ee58cb40 271ae921 ee639800 ee63989c [ 508.961336] 9ee0: 0001 ee63990c ee58cb40 c0292cbc 0007 c05442e4 c0292504 c077f97c [ 508.974074] 9f00: ee5f8000 ee5c72c0 0001 ee639800 ee5f8000 ee5f8028 ee5f8000 [ 508.986932] 9f20: 0005 c02935c0 ee825a40 0001 ee5f8000 c000e108 c003d5b8 [ 508.999755] 9f40: b6d3c000 ee5038fc ee4f9884 c0101d18 ee4f9880 ee5038f0 c023b764 [ 509.012692] 9f60: ee4f98b8 eeb9d080 ee5f8000 00f8 c000e108 ee5f8000 [ 509.025742] 9f80: 0005 c003db38 0006efae b6f4 b6f4 00f8 c003dbc4 [ 509.038900] 9fa0: c000df00 0006efae b6f4 0006ef9a b6fbc4c0 [ 509.052039] 9fc0: 0006efae b6f4 b6f4 00f8 00857898 008513f8 000171d8 0005 [ 509.065171] 9fe0: 00f8 be9a7834 b6f0a0f3 b6eaef96 6030 [ 509.078413] [c0299810] (tty_ldisc_hangup+0x3c/0x2a4) from [c0292cbc] (__tty_hangup+0x124/0x378) [ 509.097651] [c0292cbc] (__tty_hangup+0x124/0x378) from [c02935c0] (disassociate_ctty+0x7c/0x240) [ 509.117536] [c02935c0] (disassociate_ctty+0x7c/0x240) from [c003d5b8] (do_exit+0x294/0x784) [ 509.131797] [c003d5b8] (do_exit+0x294/0x784) from [c003db38] (do_group_exit+0x54/0xc8) [ 509.145622] [c003db38] (do_group_exit+0x54/0xc8) from [c003dbc4] (__wake_up_parent+0x0/0x20) [ 509.159980] Code: e2066002 e2505000 0a18 e5953000 (e5933018) [ 509.171733] ---[ end trace 0b4cd254dfcafc0c ]--- [ 509.181906] Fixing recursive fault but reboot is needed! Going back to the parent rev, d3686aa sunxi: use a 4MB malloc pool and report then :) Right, this one doesn't seem to crash; but I cant extract the .xz either... linux-sunxi/.git/objects/pack/pack-06962d550c8aab83282655647120ce3552ca5b0e.idx xz: (stdin): Compressed data is corrupt tar: Unexpected EOF in archive tar: Unexpected EOF in archive tar: Error is not recoverable: exiting now and that constantly, sometimes it gets to go 1 file further ... ironically the sha1 calculation worked fine I'll go back to pre-merge and double check that. 4271202 sunxi: add board hcore hc860 seems to be un-able to extract the tar-ball and causes an oops. [ 450.179006] [c02449fc] (__list_del_entry+0x8/0xb8) from [c0244ab8] (list_del+0xc/0x24) [ 450.199528] [c0244ab8] (list_del+0xc/0x24) from [c00e48c0] (__rmqueue+0x70/0x370) [ 450.219659] [c00e48c0] (__rmqueue+0x70/0x370) from [c00e563c] (get_page_from_freelist+0x324/0x4b8) [ 450.253607] [c00e563c] (get_page_from_freelist+0x324/0x4b8) from [c00e6154] (__alloc_pages_nodemask+0x18c/0x7b4) [ 450.289644] [c00e6154] (__alloc_pages_nodemask+0x18c/0x7b4) from [c0115560] (new_slab+0x84/0x23c) [ 450.325304] [c0115560] (new_slab+0x84/0x23c) from [c0509ad0] (__slab_alloc.constprop.54+0x20c/0x450) [ 450.362016] [c0509ad0] (__slab_alloc.constprop.54+0x20c/0x450) from [c0116e84] (kmem_cache_alloc+0x70/0x18c) [ 450.400291] [c0116e84] (kmem_cache_alloc+0x70/0x18c) from [c019cb34] (ext4_alloc_inode+0x20/0xbc) [ 450.438405] [c019cb34] (ext4_alloc_inode+0x20/0xbc) from [c0133230] (alloc_inode+0x24/0x9c) [ 450.462253] [c0133230] (alloc_inode+0x24/0x9c) from [c0134c30] (new_inode_pseudo+0x10/0x50) [ 450.486131] [c0134c30] (new_inode_pseudo+0x10/0x50) from [c0134c80] (new_inode+0x10/0x24) [ 450.509985] [c0134c80] (new_inode+0x10/0x24) from [c0184ff8] (ext4_new_inode+0x94/0xee0) [ 450.533711] [c0184ff8] (ext4_new_inode+0x94/0xee0) from [c0191318] (ext4_create+0xb0/0x150) [ 450.557750] [c0191318] (ext4_create+0xb0/0x150) from [c012905c] (vfs_create+0x98/0x11c) [ 450.581516] [c012905c] (vfs_create+0x98/0x11c) from [c01294f8] (do_last+0x418/0x7e8) [ 450.605109] [c01294f8] (do_last+0x418/0x7e8) from [c012a164] (path_openat+0xc4/0x39c) [ 450.628904] [c012a164] (path_openat+0xc4/0x39c) from [c012a530] (do_filp_open+0x34/0x80) [ 450.653058] [c012a530] (do_filp_open+0x34/0x80) from [c011b7e0] (do_sys_open+0xf0/0x17c)
Re: [linux-sunxi] Current u-boot crashes my cubietruck!
On Sun, 2014-03-30 at 12:58 +0200, Olliver Schinagl wrote: 4271202 sunxi: add board hcore hc860 seems to be un-able to extract the tar-ball and causes an oops. That's from ages ago, isn't it? Are you sure it isn't some other component which has changed recently, e.g. the kernel? 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. This is on an SSD, with a 2amps charger. I ran tinymembenches before never exceeding 0.7 amps; could someone confirm this on the cubietruck? I've just FEL booted with 2014.04-rc2-00665-g96510e1 (i.e. current u-boot-sunxi.git#sunxi) onto a SATA installation and have started a git clone of the kernel, after which I'll run a build and see what happens. Have you checked the checksum of the tarball you are extracting and tried unpacking it on a known good system? Ian. -- You received this message because you are subscribed to the Google Groups linux-sunxi group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[linux-sunxi] sun6i SPL support status update
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). 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. Regards, Hans -- You received this message because you are subscribed to the Google Groups linux-sunxi group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [linux-sunxi] [RFC PATCH u-boot 0/2] Try to improve sunxi DRAM setup code
On Fri, 2014-03-28 at 12:42 +0200, Siarhei Siamashka wrote: https://github.com/ssvb/lima-memtester I needed the following to get it to build on my Debian rootfs. (and it turns out I can't run it anyway since I'm running a mainline kernel and haven't figured out mali.ko yet, for another time I think) -8--- From 72624b5d665e576057a3a869117014ae6a998578 Mon Sep 17 00:00:00 2001 From: Ian Campbell i...@hellion.org.uk Date: Sun, 30 Mar 2014 13:09:55 +0100 Subject: [PATCH] Remove bashisms from scripts [ a == b ] is a bashism, the portable alternative is [ a = b ]. Fixes the following issue on Debian where /bin/sh == dash: # ./build-lima-memtester-static-binary.sh ./build-lima-memtester-static-binary.sh: 3: [: x: unexpected operator ./build-lima-memtester-static-binary.sh: 11: ./build-lima-memtester-static-binary.sh: -DHAVE_NO_LIBMALI_BLOB: not found The alternative would be to explicitly use #!/bin/bash in the script but since the fix is trivial we might as well make it. Signed-off-by: Ian Campbell i...@hellion.org.uk --- build-lima-memtester-static-binary.sh | 2 +- build-textured-cube-static-binary.sh | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/build-lima-memtester-static-binary.sh b/build-lima-memtester-static-binary.sh index e84e51b..d253cbb 100755 --- a/build-lima-memtester-static-binary.sh +++ b/build-lima-memtester-static-binary.sh @@ -1,6 +1,6 @@ #!/bin/sh -if [ x$CC == x ] +if [ x$CC = x ] then echo Note: using 'gcc' as a compiler. But it is possible to do something echo like \'export CC=foobar\' to override this. diff --git a/build-textured-cube-static-binary.sh b/build-textured-cube-static-binary.sh index 61f3e95..cc9f5d0 100755 --- a/build-textured-cube-static-binary.sh +++ b/build-textured-cube-static-binary.sh @@ -1,6 +1,6 @@ #!/bin/sh -if [ x$CC == x ] +if [ x$CC = x ] then echo Note: using 'gcc' as a compiler. But it is possible to do something echo like \'export CC=foobar\' to override this. -- 1.9.0 -- You received this message because you are subscribed to the Google Groups linux-sunxi group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [linux-sunxi] Current u-boot crashes my cubietruck!
On 03/30/2014 01:26 PM, Ian Campbell wrote: On Sun, 2014-03-30 at 12:58 +0200, Olliver Schinagl wrote: 4271202 sunxi: add board hcore hc860 seems to be un-able to extract the tar-ball and causes an oops. That's from ages ago, isn't it? It is! I will now use the u-boot from even older; that came with fedora19, very conservative, but also 'known to be somewhat good' Are you sure it isn't some other component which has changed recently, e.g. the kernel? Software wise, i'm running it quite conservative really, really old stuff so to say. That said the sorts of random crashed you've been posting sound a lot like either a DRAM issue or overheating. Either of which could be down to u-boot setting up something wrong or bad hardware I suppose. Overheating, maybe. It feels hottish to the touch, but can hold a finger on it without any problem whatsoever. Not close to the pain point. So I estimate 50 C? Shouldn't be reason to be concerned imo. Power might be the problem, i see the input voltage under heavy load drop to 4.65 Volts @ 0.9 amps This is on an SSD, with a 2amps charger. I ran tinymembenches before never exceeding 0.7 amps; could someone confirm this on the cubietruck? I've just FEL booted with 2014.04-rc2-00665-g96510e1 (i.e. current u-boot-sunxi.git#sunxi) onto a SATA installation and have started a git clone of the kernel, after which I'll run a build and see what happens. Cool, the strange thing is, u-boot cloned and compiled fine :( Have you checked the checksum of the tarball you are extracting and tried unpacking it on a known good system? The sha1sum matches, calculated on the board, so that's good. xz -d completed successfully! tar xvf fails however, with a big ass 5 page long oops. Olliver Ian. -- You received this message because you are subscribed to the Google Groups linux-sunxi group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [linux-sunxi] Current u-boot crashes my cubietruck!
On Sun, 2014-03-30 at 12:26 +0100, Ian Campbell wrote: I've just FEL booted with 2014.04-rc2-00665-g96510e1 (i.e. current u-boot-sunxi.git#sunxi) onto a SATA installation and have started a git clone of the kernel, after which I'll run a build and see what happens. So, I did the git clone, checkout, config and make all -j4 has been running for quite a while now (10 minutes) with no errors. While the make was running I've messed around with git archive to produce a tar.xz, got bored waiting for that, used wget to download a tar.xz from kernel.org and unpacked it. All with no errors. IOW I'm afraid it all looks OK to me. This is all running from a SATA disk with a 2A power supply. I'm about to go out for lunch, if it crashes etc while I'm out I'll let you know after I get back. This is all on a cubietruck BTW. Ian. -- You received this message because you are subscribed to the Google Groups linux-sunxi group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [linux-sunxi] Current u-boot crashes my cubietruck!
On 03/30/2014 02:25 PM, Ian Campbell wrote: On Sun, 2014-03-30 at 12:26 +0100, Ian Campbell wrote: I've just FEL booted with 2014.04-rc2-00665-g96510e1 (i.e. current u-boot-sunxi.git#sunxi) onto a SATA installation and have started a git clone of the kernel, after which I'll run a build and see what happens. So, I did the git clone, checkout, config and make all -j4 has been running for quite a while now (10 minutes) with no errors. While the make was running I've messed around with git archive to produce a tar.xz, got bored waiting for that, used wget to download a tar.xz from kernel.org and unpacked it. All with no errors. IOW I'm afraid it all looks OK to me. This is all running from a SATA disk with a 2A power supply. I'm about to go out for lunch, if it crashes etc while I'm out I'll let you know after I get back. Looking forward to the result, but I'm sure it'll be fine ;) So i changed to the u-boot that comes with fedora 19 from hans, as I did all my previous work with that, and untarring of the extracted tarball works now. I have to make a deadline for my book (building the BSP, hence i bumped into this) and will do more compile/extraction tests in the next few days as time permits on hans's u-boot. I'll run some of ssvb's benchmarks to test various things. If this is all deemed stable; then it can only be u-boot that somehow broke. The only thing I can imagine is tolerances or power usage somehow. Speaking of, during the extraction power jumped from just under 0.5 amps @ 4.85V = idle; to about 0.85 amps @ 4.75V. Olliver This is all on a cubietruck BTW. ditto ;) Ian. -- You received this message because you are subscribed to the Google Groups linux-sunxi group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[linux-sunxi] Issue - [cpu_freq] ERR:try to get regulator failed, core vdd will not changed!
for 3.4 kernel, it fail to get regulator. who know what happen. I was
tracing the issue without success :P
anyone can help ? thanks
kernel: linux-sunxi/stage/sunxi-3.4
CODE:
drivers/power/axp_power/virtual20.c
static int regulator_virtual_consumer_probe(struct platform_device *pdev)
{
char *reg_id = pdev-dev.platform_data;
struct virtual_consumer_data *drvdata;
int ret, i;
pr_warning([%s] enter1, pdev=%s, reg_id=%s\n, __FUNCTION__,
pdev-name, reg_id);
drvdata = kzalloc(sizeof(struct virtual_consumer_data), GFP_KERNEL);
if (drvdata == NULL) {
pr_warning([%s] enter 2\n, __FUNCTION__);
ret = -ENOMEM;
goto err;
}
mutex_init(drvdata-lock);
pr_warning([%s] pdev=%p, reg_id=%s\n, __FUNCTION__, pdev, reg_id);
//drvdata-regulator = regulator_get(pdev-dev, reg_id);
drvdata-regulator = regulator_get(NULL, reg_id);
- Bug ?
//drvdata-regulator = regulator_get(NULL, axp20_analog/fm);
if (IS_ERR(drvdata-regulator)) {
ret = PTR_ERR(drvdata-regulator);
pr_warning([%s] enter3\n, __FUNCTION__);
goto err;
}
and I found the error platform reg-20-cs-ldo2: Driver reg-20-cs-ldo2
requests probe deferral is caused by the function
static int really_probe(struct device *dev, struct device_driver *drv)
at drivers/base/dd.c
LOGS:
[4.604562] Registering the dns_resolver key type
6VFP support v0.3: [4.611237] VFP support v0.3: implementor 41
architecture 2 part 30 variant 7 r4
implementor 41 architecture 2 part 30 variant 7 rev 4
5Registering SWP/SWPB emulation handler
[4.627459] Registering SWP/SWPB emulation handler
4[_regulator_get] 2
[4.634326] [_regulator_get] 2
4[_regulator_get] 3
[4.639396] [_regulator_get] 3
3[cpu_freq] ERR:try to get regulator failed, core vdd will not changed!
[4.648956] [cpu_freq] ERR:try to get regulator failed, core vdd will
not changed!
6[cpu_freq] INF:---V-F Table---
[4.662395] [cpu_freq] INF:---V-F
Table---
6[cpu_freq] INF: voltage = 1450mvfrequency = 1008MHz
[4.674309] [cpu_freq] INF: voltage = 1450mvfrequency = 1008MHz
6[cpu_freq] INF: voltage = 1425mvfrequency = 912MHz
[4.685442] [cpu_freq] INF: voltage = 1425mvfrequency = 912MHz
6[cpu_freq] INF: voltage = 1350mvfrequency = 864MHz
[4.696585] [cpu_freq] INF: voltage = 1350mvfrequency = 864MHz
6[cpu_freq] INF: voltage = 1250mvfrequency = 720MHz
[4.707732] [cpu_freq] INF: voltage = 1250mvfrequency = 720MHz
6[cpu_freq] INF: voltage = 1150mvfrequency = 528MHz
[4.718871] [cpu_freq] INF: voltage = 1150mvfrequency = 528MHz
6[cpu_freq] INF: voltage = 1100mvfrequency = 312MHz
[4.730004] [cpu_freq] INF: voltage = 1100mvfrequency = 312MHz
6[cpu_freq] INF: voltage = 1050mvfrequency = 144MHz
[4.741137] [cpu_freq] INF: voltage = 1050mvfrequency = 144MHz
6[cpu_freq] INF: voltage = 1000mvfrequency =0MHz
[4.752272] [cpu_freq] INF: voltage = 1000mvfrequency =0MHz
6[cpu_freq] INF:---
[4.764188] [cpu_freq]
INF:---
6[cpu_freq] INF:sunxi_cpufreq_initcall, get cpu frequency from sysconfig,
max freq: 1008MHz, min freqz
[4.780882] [cpu_freq] INF:sunxi_cpufreq_initcall, get cpu frequency
from sysconfig, max freq: 1008Mz
6registered taskstats version 1
[4.795506] registered taskstats version 1
4[really_probe] hdmi, hdmi
[4.803665] [really_probe] hdmi, hdmi
6I2C: i2c-5: HDMI I2C adapter
[4.810606] I2C: i2c-5: HDMI I2C adapter
6disp clks: lcd 7425 pre_scale 1 hdmi 7425 pll 29700 2x 0
[4.843568] disp clks: lcd 7425 pre_scale 1 hdmi 7425 pll
29700 2x 0
6Console: switching to colour frame buffer device 160x45
[5.405836] Console: switching to colour frame buffer device 160x45
4[really_probe] 5
[5.431016] [really_probe] 5
6sunxi-rtc sunxi-rtc: setting system clock to 2010-01-01 00:00:00 UTC
(1262304000)
[5.441668] sunxi-rtc sunxi-rtc: setting system clock to 2010-01-01
00:00:00 UTC (1262304000)
4BENN axp_regulator_init
[5.452640] BENN axp_regulator_init
4BENN axp_battery_init
[5.458493] BENN axp_battery_init
4BENN regulator_virtual_consumer_init
[5.465433] BENN regulator_virtual_consumer_init
4BENN virtual_init
[5.472241] BENN virtual_init
4[really_probe] reg-20-cs-ldo2, reg-20-cs-ldo2
[5.479698] [really_probe] reg-20-cs-ldo2, reg-20-cs-ldo2
4[regulator_virtual_consumer_probe] enter1, pdev=reg-20-cs-ldo2,
reg_id=axp20_analog/fm
[5.493018] [regulator_virtual_consumer_probe] enter1,
pdev=reg-20-cs-ldo2, reg_id=axp20_analog/fm
4[regulator_virtual_consumer_probe] pdev=c08b7378,
Re: [linux-sunxi] Re: A20 + OV5640 (parallel) issues
Luckily not yet, it goes directly to the screen - this would be the next potential project. However, when I see how many issues disp driver has (and it's somewhat documented), I cannot imagine the issues with the VPU that you're having, knowing that even registers are not documented... Hopefully, it'll be a bit more functional when I get the second project. On Saturday, March 29, 2014 10:56:49 PM UTC+1, Jon Smirl wrote: On Sat, Mar 29, 2014 at 4:34 PM, Ivan Kozic jimm...@gmail.comjavascript: wrote: Hey getting closer :) There's still an issue with the LDO (I don't like this debugfs issue) - check if you actually get sensor voltage first. If no, there's still something funny going on with AXP, so triple-check the Fex file for LDO init. Check with a multimeter whether you really get 2V8. Ok, so the I2C stuff is located in the driver itself - just look at the functions in the mt9d112 driver file (something like sensor_read and sensor_write) - there you should see if the sensor address is correct. Also bear in mind which I2C bus is used for sensor in the fex file for your sensor - mine is twi0, but it can easily be that you've connected the sensor to something else (on Olinuxino twi2 was also close to route for instance so I made assembly options on my interface to either use TWI0 or TWI2, as I didn't really know what is implemented in the kernel and what's not at the time...). If you're using level converters for I2C, check them as well, especially OE's. Are you planning on feeding this into the h.264 compression engine? That's where I got stuck with not enough compression being done - output stream is too many MB/s. On Fri, Mar 28, 2014 at 11:47 PM, rdv...@gmail.com javascript: wrote: пятница, 28 марта 2014 г., 11:41:49 UTC+2 пользователь Ivan Kozic написал: Hi, You haven't given much info about this - take care with Cubieboard 1 2 - as far as I can remember they don't have PIXCLK routed for CSI0 port, so it's completely unusable. You should use CSI1. Regarding the seg fault - not sure how you connected the power supplies to the sensor, but these regulator_enable are for AXP IC - if you connected the sensor to the AXP, you need to use them I guess. I for instance have just connected the sensor supply to fixed LDO's coming from either 3V3 or 5V, which is always alive, so I don't really need them, but nevertheless they aren't commented out in my driver (WiP, so still dirty) and they are working, so maybe the culprit is something else. You didn't say which test application or given any snippets, but if it's the one coming with the driver (app_test_ok or something similar), by Rockie Cheng (this name always amuses me :) ), then it's full of bugs and issues and you should carefully go through every step and clean the crap code out (a lot of it is crap). Better yet, write a much simpler V4L2 test app yourself. Things that also pop is the old kernel (I'm using 3.4.75 and this is already like couple of months old) and this Linaro rootfs (don't know about this - is it fully supported on Cubies?). You should probably use newer kernel just to be sure that something stupid is not breaking. Also take care with drivers - the one for OV5640 is very badly written and full of bugs and I don't think that the supplied sensor settings are usable for anyone (they are all like 3.75 and 7.5 fps, most of them just wrong). Also sun4i_csi driver is bad (you can read some of the issues on this thread, but there are other threads as well). So mostly for a functional system all this needs to be cleaned and rewritten. On Thursday, March 27, 2014 11:54:08 PM UTC+1, rdv...@gmail.com wrote:Hello guys, I want to get camera module mt9d112 working on cubieboard a10 over CSI. I am using ubuntu linaro with kernel version 3.4.61. Test application crashes with seg fault on (regulator_enable+0x4/0x1f8) from [bf010138] (sensor_power+0x190/0x398 [mt9d112]). Could you please help me to figure out where the issue is? How can I debug kernel module? You are right for testing I using app_test_ok. This test application is full of mistakes but for now I did not even successfuly initialized camera module. I have connected VCC of camera module to CSI1_IO_2V8 pin on the board and other pins to the rest of CSI ports. The CSI1_IO_2V8 is actually LDO4 of AXP20 and I finally found in AllWinner documentation that string axp_hdmi should be used in script.fex instead of axp_p11 as described in tutorial. By the way the tutorial from cubieboard is full of such mistakes. So, when I change settings string to axp_hdmi I get new portion of errors: [ 383.721765] [CSI]Welcome to CSI driver [ 383.723657] [CSI]csi_init [
Re: [linux-sunxi] Current u-boot crashes my cubietruck!
On Sun, 2014-03-30 at 13:25 +0100, Ian Campbell wrote: I'm about to go out for lunch, if it crashes etc while I'm out I'll let you know after I get back. It was fine. I've left it running in a loop repeatedly building kernels. Ian. -- You received this message because you are subscribed to the Google Groups linux-sunxi group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [linux-sunxi] Current u-boot crashes my cubietruck!
On 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. Ian. -- You received this message because you are subscribed to the Google Groups linux-sunxi group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[linux-sunxi] Azpen A727 / A23 chip
I just got an Azpen A727 (some reason it's not on the company's website), it runs the A23 chip. I managed to find the serial TX but RX is still unknown. I started a wiki page, http://linux-sunxi.org/A727 . If anyone has any specific ideas or anyway I can help, I'm willing to probe it some more. Dan -- You received this message because you are subscribed to the Google Groups linux-sunxi group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. 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 Sun, 30 Mar 2014 13:13:29 +0100 Ian Campbell i...@hellion.org.uk wrote: On Fri, 2014-03-28 at 12:42 +0200, Siarhei Siamashka wrote: https://github.com/ssvb/lima-memtester I needed the following to get it to build on my Debian rootfs. Thanks for the fix, pushed to github. (and it turns out I can't run it anyway since I'm running a mainline kernel and haven't figured out mali.ko yet, for another time I think) Yes, right now it needs sunxi-3.4 kernel, which is a bit more feature complete at the moment. That's a good point, appears that readme.txt also needs to be improved for more clarity. In the mainline kernel we first need a display driver (sunxi-kms?), which would provide emulation of the linux framebuffer interface among other things. And then, I guess, the mali400 kernel driver could be used with a bit of adaptation. -8--- From 72624b5d665e576057a3a869117014ae6a998578 Mon Sep 17 00:00:00 2001 From: Ian Campbell i...@hellion.org.uk Date: Sun, 30 Mar 2014 13:09:55 +0100 Subject: [PATCH] Remove bashisms from scripts [ a == b ] is a bashism, the portable alternative is [ a = b ]. Fixes the following issue on Debian where /bin/sh == dash: # ./build-lima-memtester-static-binary.sh ./build-lima-memtester-static-binary.sh: 3: [: x: unexpected operator ./build-lima-memtester-static-binary.sh: 11: ./build-lima-memtester-static-binary.sh: -DHAVE_NO_LIBMALI_BLOB: not found The alternative would be to explicitly use #!/bin/bash in the script but since the fix is trivial we might as well make it. Signed-off-by: Ian Campbell i...@hellion.org.uk --- build-lima-memtester-static-binary.sh | 2 +- build-textured-cube-static-binary.sh | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/build-lima-memtester-static-binary.sh b/build-lima-memtester-static-binary.sh index e84e51b..d253cbb 100755 --- a/build-lima-memtester-static-binary.sh +++ b/build-lima-memtester-static-binary.sh @@ -1,6 +1,6 @@ #!/bin/sh -if [ x$CC == x ] +if [ x$CC = x ] then echo Note: using 'gcc' as a compiler. But it is possible to do something echo like \'export CC=foobar\' to override this. diff --git a/build-textured-cube-static-binary.sh b/build-textured-cube-static-binary.sh index 61f3e95..cc9f5d0 100755 --- a/build-textured-cube-static-binary.sh +++ b/build-textured-cube-static-binary.sh @@ -1,6 +1,6 @@ #!/bin/sh -if [ x$CC == x ] +if [ x$CC = x ] then echo Note: using 'gcc' as a compiler. But it is possible to do something echo like \'export CC=foobar\' to override this. -- You received this message because you are subscribed to the Google Groups linux-sunxi group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [linux-sunxi] Azpen A727 / A23 chip
On 03/30/2014 07:17 PM, Daniel J. Grinkevich wrote: I just got an Azpen A727 (some reason it's not on the company's website), it runs the A23 chip. I managed to find the serial TX but RX is still unknown. I started a wiki page, http://linux-sunxi.org/A727 . If anyone has any specific ideas or anyway I can help, I'm willing to probe it some more. You could try by going over the New_Device_Howto though a lot of things might not work out right away. a10-meminfo won't work for example. Even so, having gone over the New_Device_Howto should get us a little bit closer. Thanks for taking the time and effort! Olliver Dan -- You received this message because you are subscribed to the Google Groups linux-sunxi group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com mailto:linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups linux-sunxi group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [linux-sunxi] Re: New u-boot sunxi-next available for testing
Am Donnerstag, 27. März 2014 19:50:32 UTC+1 schrieb Ezaul Zillmer: Ok Muito Obrigado! ;) Em quinta-feira, 27 de março de 2014 15h19min58s UTC-3, Hans de Goede escreveu:Hi, To build this you should do: make ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf- Cubieboard2_config make ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf- Regards, Hans On 03/27/2014 06:33 PM, Ezaul Zillmer wrote: Good Afternoon Doctor Hans Updated my u-boot I wonder how was the logic I tried to compile it like this: ./mkconfig ARCH=arm CPU=armv7 SOC=sunxi BOARD=Cubieboard2 make ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf- No dick: (could correct me where I am going wrong! Hug Since Thank you much longer Hi Hans, I tested the new u-boot with your newest kernel (3.14.0-rc8+) on the cubietruck. I found two issues so far. It seems that only one CPU is initialized correctly: [0.049402] /cpus/cpu@0 missing clock-frequency property [0.049433] /cpus/cpu@1 missing clock-frequency property [0.049447] CPU0: thread -1, cpu 0, socket 0, mpidr 8000 [0.049479] Setting up static identity map for 0x4073f2d0 - 0x4073f368 [0.058595] CPU1: failed to boot: -38 [0.058647] Brought up 1 CPUs [0.058655] SMP: Total of 1 processors activated. [0.058662] CPU: All CPU(s) started in SVC mode. [0.059721] devtmpfs: initialized [0.064475] VFP support v0.3: implementor 41 architecture 2 part 30 variant 7 rev 4 Also kvm does not work and there is no /dev/kvm device. [0.176760] kvm [1]: HYP mode not available Here is the full dmesg output: http://pastebin.com/V72FAzmp Greetings Markus -- 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.
