Jump to content

monti

Members
  • Posts

    37
  • Joined

  • Last visited

  1. Hi, you can also try the built-in watchdog. But unfortunatelly, event that's not always working reliable (maybe the Power-Chip goes into safe mode, which is before the processor-watchdog)
  2. See here: http://forum.armbian.com/index.php/topic/31-problems-with-gigabit/ Some boards are nearly perfect, other can't be used with GBit. Seems to be a A20-Problem.
  3. Hi again & a happy new year... Is there a possibility for a low-level-NAND-Tools? I need it only for updating uImage-file, which resides inside the nand. Who is the main developer? boris.brezillon?
  4. Ok, 3.4.110 too Message from syslogd@localhost at Jan 1 21:38:52 ... kernel:[ 556.108806] Internal error: Oops: 17 [#1] PREEMPT SMP ARM Message from syslogd@localhost at Jan 1 21:38:52 ... kernel:[ 556.839929] Process kworker/u:0 (pid: 5, stack limit = 0xef05a2f0) Message from syslogd@localhost at Jan 1 21:38:52 ... kernel:[ 556.849870] Stack: (0xef05bd78 to 0xef05c000)
  5. Probably. With bad boards, I noticed that the transfer rate with mass transfers is nearly the top rate (25 MBytes/s), even with such a packet loss. Probably because the tcp stack notices the missing packets from ack's of later packets. With slow transfers (only some packets per seconds like typing into a command shell), the response is bad. So for every 10-25% of key strokes the response cames a second later, which is annoying for me. I'm also not sure, which speed is better...
  6. You may try to disable the cpu-govenor (set it to performance govenor). On my Lime2s it helped. The hardware watchdog works in tests, but in my cases never in real crashes.
  7. Hi Dario, unfortunatelly, only a workaround. If you limit the connection to 100MBit, its working very reliable without packet loss. (something like "ethtool eth0 100M-Base-FD"). With some bad boards you get a better connection than with 1G. So apr. 25% of the board have loss time up to 5% (good for lime2), 50% up to 10% (you can work with it) and the remaining board are above 10% (100MBit is often better). Latest kernel doesn't help. According to tkaiser, other boards seems to have the same behaviour (Lamobo R1 and Banana Pi), so its probable an A20 problem. Also changing the RX/TX-Parameter or the cpu-frequency do not help. We are considering to use another boards with another chips on the long run. We have also problems with the watchdog, which isnt working reliable, probably because the power chip switchs to a "safe state" under some cases.
  8. No, these ones not. 45-52°C normally. But this is not the problem in this case because if you have max load, the ondemand governor will also speed up to 1 GHz. Just try it and tell us if it gets better or not! Not even a restart is required, but verify it with cpufreq-info before and later if the performance is really running.
  9. Don't know. I've a SSD on board and a very simple power meter. With ondemand ~3W, with performance ~3W Maybe you will waste 0,5W. If it works, you may get reliability for 1$/year ;-)
  10. The ondemand or interactive governor switches the cpu frequence. Additional to the frequency, the voltage is changed too, which may be problematic. This file may be new, you have to create it (exactly "/etc/default/cpufrequtils"). It' read in /etc/init.d/cpufrequtils: ENABLE="true" GOVERNOR="interactive" MAX_SPEED="1010000" MIN_SPEED="480000" ... if [ -f /etc/default/cpufrequtils ] ; then . /etc/default/cpufrequtils fi You may also restart only this service-script, probably.
  11. Oh, I had this problems too. (every few weeks at two of ~10 boards). The hardware watchdog is also not working. Its independent from the power supply. Try to disable the frequency switching in /etc/default/cpufrequtils: GOVERNOR="performance" and reboot. Now it runs stable since months with 1GHz on all boards. Maybe that the Power-Chip AXP209 detects some under/overvoltage and stops the whole system while changing frequency and voltage. Btw. I had also some kernel panics while reading the cpu frequency from the proc system.
  12. Good morning Igor, I tested it practically Unfortunatelly, I'm not a kernel specialist, so I do not really know, what I'm doing. Regarding the driver: - don't know how to test. According to the config file its enabled. root@lime2:~# cat /boot/config-4.2.4-sunxi | grep NAND | grep -v \# CONFIG_MTD_NAND_ECC=y CONFIG_MTD_NAND=y CONFIG_MTD_NAND_IDS=y CONFIG_MTD_NAND_SUNXI=y But if its operational: In syslog/messages: nothing about mtd or nand (case insensitive), so maybe/maybe not.
  13. Would be too easy if it works. - Applied this path to lime2.dts and the dtsi (corrected @-signs and the paths). - make ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf- all zImage - Copied the new *lime2.dtb into /boot/dtb - Reboot - None This seems to be correct or did I forget to adapt some placeholder? (size-cells) &nfc { pinctrl-names = "default"; pinctrl-0 = <&nand_pins_a &nand_cs0_pins_a &nand_rb0_pins_a>; status = "okay"; nand@0 { #address-cells = <2>; #size-cells = <2>; reg = <0>; allwinner,rb = <0>; nand-ecc-mode = "hw"; nand-ecc-strength = <40>; nand-ecc-step-size = <1024>; nand-rnd-mode = "hw"; nand-randomizer-seeds = /bits/ 16 < 0x2b75 0x0bd0 0x5ca3 0x62d1 0x1c93 0x07e9 0x2162 0x3a72 0x0d67 0x67f9 0x1be7 0x077d 0x032f 0x0dac 0x2716 0x2436 0x7922 0x1510 0x3860 0x5287 0x480f 0x4252 0x1789 0x5a2d 0x2a49 0x5e10 0x437f 0x4b4e 0x2f45 0x216e 0x5cb7 0x7130 0x2a3f 0x60e4 0x4dc9 0x0ef0 0x0f52 0x1bb9 0x6211 0x7a56 0x226d 0x4ea7 0x6f36 0x3692 0x38bf 0x0c62 0x05eb 0x4c55 0x60f4 0x728c 0x3b6f 0x2037 0x7f69 0x0936 0x651a 0x4ceb 0x6218 0x79f3 0x383f 0x18d9 0x4f05 0x5c82 0x2912 0x6f17 0x6856 0x5938 0x1007 0x61ab 0x3e7f 0x57c2 0x542f 0x4f62 0x7454 0x2eac 0x7739 0x42d4 0x2f90 0x435a 0x2e52 0x2064 0x637c 0x66ad 0x2c90 0x0bad 0x759c 0x0029 0x0986 0x7126 0x1ca7 0x1605 0x386a 0x27f5 0x1380 0x6d75 0x24c3 0x0f8e 0x2b7a 0x1418 0x1fd1 0x7dc1 0x2d8e 0x43af 0x2267 0x7da3 0x4e3d 0x1338 0x50db 0x454d 0x764d 0x40a3 0x42e6 0x262b 0x2d2e 0x1aea 0x2e17 0x173d 0x3a6e 0x71bf 0x25f9 0x0a5d 0x7c57 0x0fbe 0x46ce 0x4939 0x6b17 0x37bb 0x3e91 0x76db>; onfi,nand-timing-mode = <0x1f>; /* main@400000 { label = "main"; reg = /bits/ 64 <0x400000 0xffc00000>; }; */ }; };
  14. Made a fresh install with 4.2.4 (nothing worked with 4.2.3), now this seems to compile. - Switched on then NAND_SUNXI-Driver CONFIG_MTD_NAND_SUNXI=y --> compiles and runs But no nand visible, probably because no nand is configured in the dtb. I think, something like this is missing: http://lists.denx.de/pipermail/u-boot/2015-June/215988.html This is for the lime, but the lime2 should be the same regarding nand.
×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines