tricolery
-
Posts
20 -
Joined
-
Last visited
Content Type
Forums
Store
Crowdfunding
Applications
Events
Raffles
Community Map
Posts posted by tricolery
-
-
Hello everyone. I'm experiencing some strange issue with my cubieboard and its connection to the internet.
I boot it up and it works correctly, but after a day or two, I can't communicate with it using a ssh program, or vnc viewer. My other two servers that uses Linux Mint is working normally, so I think the problem is not my router. (I even swapped the Ethernet cables between my servers).
If I connect a display on my cubieboard and try to ping my Windows computer, then I'm able to ssh my cubieboard using my computer.
Sometimes I'm unable to connect to my cubieboard via ssh using my windows and my Android phone, but if I try using my Linux machine, I can connect with ssh with no problems.
I thought I was facing that issue with memory clock an my cubieboard was turning off again, but when I connected a display on it, I found out that it was working ( and I was able to use the internet on it, so it still had a connection to the internet, but my three oder computers could not connect to it.
Did someone experienced an issue like this one?
Sent from my SM-G930F using Tapatalk
-
BTW, even though non-legacy image starts ok, it don't see NAND on my Cubie2. I tried to run Android and Lubuntu Desk from NAND - anyway nand-sata-install (when then I boot Armbian from TF) tells "No target". What a disappointment!
Tricolery, thanx, I have Debian Jessie on my Win7 (on VMWare). It must be usable for this. But could you be more specific in 7th chapter? Where I can get u-boot 5.23?
Its on my second post of this thread. As I told you, you need any woking uboot just to boot the cubie board and roll back the uboot to 2.53 using your package manager. If you want especificaly the uboot 5.23, you will need to compile it.
-
So long time same issue - bad bootloader in all legacy kernels! Dear Igor, please fix it at last!
Member tricolery, pls write step-by-step manual to get board with legacy alive. I don't know how to flash u-boot and where to get v.5.23.
Its very easy, dude.
1. You will need a linux machine. (Don't know if it is possible to do it in windows). If you cant install linux on your PC, just try a live version with a pendrive on your PC or you can even flash lubuntu or cubian on your cubieboard NAND.
2. Insert your SD card on the machine you are using.
3. Discover de drive name linux has assigned to you SD card. (A veeery easy way to do it without any code, is to access /dev/ with your linux distro file manager, select all the devices there and leave it selected. Then you insert the memory card on your computer. The files that appeared and is not selected, is your memory card. As a example, mine appeared sdd and sdd1. I applied the uboot on sdd with out th "1". Other way you can do it is typing "lsblk" on your terminal and from the output of that command, find your SD card drive name.
4. Download and extract the uboot. Extract it at any place. (With a simple name to asure we dont have any trouble here)
5. Use the comand sudo dd if=/path_to_your_u-boot/u-boot-sunxi-with-spl.bin of=/dev/your_sdcard_drive_name bs=1024 seek=8 (use sudo for this command even on a live distro. The output of this command should be something like xxxxx bytes writen)
6. Try boot the cubieboard
7. Force version 5.23 of uboot to be installed. If you dont know how to do it with bash, install synapitc (It's apt-get with a UI). (If I remember well, synapitc is not installed on igor image)
Brotips: If you use a nand image on cubieboard to fix SD Card, your sd card drive name should be something like mmcblk0. On your PC, most of the linux distros will usualy mount your sdcard as sdx, for x a letter from a to z.
If you dont know what linux you can use on your PC, you can use Mint, a very lightweight and easy to use distro. Just go with the 32-bit version(It can use more than 4GB of RAM, but that's another story). Burn a disk with it or search how to use it on a pendrive.
-
-
Yes, this is happening with my cubieboard 2 too.
-
Did you have time to test anything?
Yes, I tested it this weekend. With 456 MHz, the test fails after 4 hours running. I used Lima-memtester.
-
Are you sure about this? Which U-Boot repository are you using?
If I build the mainline U-Boot for Cubieboard2 via
git clone git://git.denx.de/u-boot.git cd u-boot make CROSS_COMPILE=arm-linux-gnueabihf- Cubieboard2_defconfig make CROSS_COMPILE=arm-linux-gnueabihf- -j8
Then the ".config" file contains CONFIG_DRAM_MBUS_CLK=300. And everyone else seems to have 300MHz MBUS clock speed, based on the logs posted here.
I'm using this repository: https://github.com/linux-sunxi/u-boot-sunxi
Its the only one I managed to work on my cubie.
Is it dangerous to run MBUS 400 MHz @ 1300 mV? Can this cause any damage on the board?
Also, it looks like I dont understand what is mainline. Could you please explain to me? I read mainline many times here, but I dont know if they are all the same thing.
But yes, the DCDC3 voltage seems to be correctly set to 1.30V, so the high MBUS clock speed should be OK.
The culprit is probably the SK Hynix DRAM chips. I think that Cubieboard2 was initially developed and tested with the DRAM chips from GT. But the change to a different DRAM chips vendor now may require some different and more conservative settings. Please try to run lima-memtester with 432, 456 and 480 clock speeds for DRAM and find the last clock speed where the test passes and the first clock speed where it starts failing.
I will test this on the weekend. This week I have some tests at university and I will be very busy.
I will only need to test 456, since 432 and 480 have already been tested.
-
I see that the MBUS clock speed is set to 400MHz instead of 300MHz. This should work fine, as long as the DCDC3 voltage is set to 1.30V instead of 1.25V
You can check the DCDC3 voltage information in the dmesg log. And there was a patch for the 3.4 kernel to ensure that the kernel does not try to change the DCDC3 voltage, previously configured by the bootloader - https://github.com/linux-sunxi/linux-sunxi/commit/5052b83aa44dc16d6662d8d9d936166c139ad8c5
Please note that the mainline U-Boot currently uses 300MHz MBUS clock speed for Cubieboard2 / Cubietruck. There were so many broken 3.4 kernel forks that it was better be safe than sorry
Regarding the DRAM performance with different DRAM / MBUS clock speeds, some information can be found here: https://linux-sunxi.org/A10_DRAM_Controller_Performance
I think Igor took care of it:
[ 1.529300] axp20_ldo1: 1300 mV [ 1.534695] usb 2-1: new high-speed USB device number 2 using sw-ehci [ 1.539955] axp20_ldo2: 1800 <--> 3300 mV at 3000 mV [ 1.545230] axp20_ldo3: 700 <--> 3500 mV at 2800 mV [ 1.550356] axp20_ldo4: 1250 <--> 3300 mV at 2800 mV [ 1.555716] axp20_buck2: 700 <--> 2275 mV at 1450 mV [ 1.571542] axp20_buck3: 700 <--> 3500 mV at 1300 mV [ 1.576398] axp20_ldoio0: 1800 <--> 3300 mV at 2800 mV
I used the mainline U-Boot to make my U-Boot. The only thing I changed was DRAM speed to 432 MHz.
I wonder why MBUS is working at 400 MHz.
-
It's a SK Hynix chip H5TQ4G63AFR-PBC
Above it is a i2c rtc module I use to sync the time.
And here is the output of a10-meminfo (improved version):
./a10-meminfo dram_clk = 432 mbus_clk = 400 dram_type = 3 dram_rank_num = 1 dram_chip_density = 4096 dram_io_width = 16 dram_bus_width = 32 dram_cas = 9 dram_zq = 0x7f (0x5294a00) dram_odt_en = 0 dram_tpr0 = 0x42d899b7 dram_tpr1 = 0xa090 dram_tpr2 = 0x22a00 dram_tpr3 = 0x0 dram_emr1 = 0x4 dram_emr2 = 0x10 dram_emr3 = 0x0 dqs_gating_delay = 0x05050505 active_windowing = 0
And here is the output of tinymembrench:
tinymembench v0.4.9 (simple benchmark for memory throughput and latency) ========================================================================== == Memory bandwidth tests == == == == Note 1: 1MB = 1000000 bytes == == Note 2: Results for 'copy' tests show how many bytes can be == == copied per second (adding together read and writen == == bytes would have provided twice higher numbers) == == Note 3: 2-pass copy means that we are using a small temporary buffer == == to first fetch data into it, and only then write it to the == == destination (source -> L1 cache, L1 cache -> destination) == == Note 4: If sample standard deviation exceeds 0.1%, it is shown in == == brackets == ========================================================================== C copy backwards : 238.4 MB/s (0.5%) C copy backwards (32 byte blocks) : 671.9 MB/s (1.1%) C copy backwards (64 byte blocks) : 681.0 MB/s (0.7%) C copy : 535.3 MB/s (0.2%) C copy prefetched (32 bytes step) : 586.9 MB/s (0.7%) C copy prefetched (64 bytes step) : 601.3 MB/s (1.4%) C 2-pass copy : 524.5 MB/s C 2-pass copy prefetched (32 bytes step) : 529.4 MB/s (0.4%) C 2-pass copy prefetched (64 bytes step) : 525.5 MB/s (0.3%) C fill : 1655.1 MB/s (1.1%) C fill (shuffle within 16 byte blocks) : 1659.7 MB/s (1.3%) C fill (shuffle within 32 byte blocks) : 321.6 MB/s (1.9%) C fill (shuffle within 64 byte blocks) : 345.3 MB/s (1.9%) --- standard memcpy : 517.3 MB/s (1.0%) standard memset : 1644.4 MB/s (0.6%) --- NEON read : 1039.0 MB/s (1.4%) NEON read prefetched (32 bytes step) : 1087.6 MB/s (0.8%) NEON read prefetched (64 bytes step) : 1104.4 MB/s (1.1%) NEON read 2 data streams : 351.8 MB/s (0.8%) NEON read 2 data streams prefetched (32 bytes step) : 666.7 MB/s (0.8%) NEON read 2 data streams prefetched (64 bytes step) : 705.1 MB/s (0.4%) NEON copy : 533.8 MB/s (0.4%) NEON copy prefetched (32 bytes step) : 578.8 MB/s (1.1%) NEON copy prefetched (64 bytes step) : 594.1 MB/s (1.3%) NEON unrolled copy : 532.4 MB/s (0.7%) NEON unrolled copy prefetched (32 bytes step) : 532.0 MB/s (0.4%) NEON unrolled copy prefetched (64 bytes step) : 536.4 MB/s (0.6%) NEON copy backwards : 693.6 MB/s (1.0%) NEON copy backwards prefetched (32 bytes step) : 718.3 MB/s (0.9%) NEON copy backwards prefetched (64 bytes step) : 744.9 MB/s (1.2%) NEON 2-pass copy : 528.9 MB/s (0.7%) NEON 2-pass copy prefetched (32 bytes step) : 532.0 MB/s (0.4%) NEON 2-pass copy prefetched (64 bytes step) : 535.1 MB/s (0.9%) NEON unrolled 2-pass copy : 514.9 MB/s (0.2%) NEON unrolled 2-pass copy prefetched (32 bytes step) : 522.3 MB/s (0.8%) NEON unrolled 2-pass copy prefetched (64 bytes step) : 524.2 MB/s NEON fill : 1660.5 MB/s (1.0%) NEON fill backwards : 1726.6 MB/s (1.6%) VFP copy : 534.7 MB/s (1.2%) VFP 2-pass copy : 524.2 MB/s (0.9%) ARM fill (STRD) : 1638.8 MB/s (1.4%) ARM fill (STM with 8 registers) : 1660.5 MB/s (0.7%) ARM fill (STM with 4 registers) : 1661.8 MB/s (0.3%) ARM copy prefetched (incr pld) : 567.5 MB/s (0.4%) ARM copy prefetched (wrap pld) : 594.5 MB/s (1.9%) ARM 2-pass copy prefetched (incr pld) : 518.7 MB/s (0.3%) ARM 2-pass copy prefetched (wrap pld) : 518.3 MB/s (0.3%) ========================================================================== == Framebuffer read tests. == == == == Many ARM devices use a part of the system memory as the framebuffer, == == typically mapped as uncached but with write-combining enabled. == == Writes to such framebuffers are quite fast, but reads are much == == slower and very sensitive to the alignment and the selection of == == CPU instructions which are used for accessing memory. == == == == Many x86 systems allocate the framebuffer in the GPU memory, == == accessible for the CPU via a relatively slow PCI-E bus. Moreover, == == PCI-E is asymmetric and handles reads a lot worse than writes. == == == == If uncached framebuffer reads are reasonably fast (at least 100 MB/s == == or preferably >300 MB/s), then using the shadow framebuffer layer == == is not necessary in Xorg DDX drivers, resulting in a nice overall == == performance improvement. For example, the xf86-video-fbturbo DDX == == uses this trick. == ========================================================================== NEON read (from framebuffer) : 49.1 MB/s (0.4%) NEON copy (from framebuffer) : 48.8 MB/s (1.4%) NEON 2-pass copy (from framebuffer) : 48.2 MB/s (0.5%) NEON unrolled copy (from framebuffer) : 47.7 MB/s (0.3%) NEON 2-pass unrolled copy (from framebuffer) : 47.6 MB/s (0.3%) VFP copy (from framebuffer) : 260.7 MB/s VFP 2-pass copy (from framebuffer) : 270.1 MB/s (0.3%) ARM copy (from framebuffer) : 178.1 MB/s (0.6%) ARM 2-pass copy (from framebuffer) : 163.8 MB/s ========================================================================== == Memory latency test == == == == Average time is measured for random memory accesses in the buffers == == of different sizes. The larger is the buffer, the more significant == == are relative contributions of TLB, L1/L2 cache misses and SDRAM == == accesses. For extremely large buffer sizes we are expecting to see == == page table walk with several requests to SDRAM for almost every == == memory access (though 64MiB is not nearly large enough to experience == == this effect to its fullest). == == == == Note 1: All the numbers are representing extra time, which needs to == == be added to L1 cache latency. The cycle timings for L1 cache == == latency can be usually found in the processor documentation. == == Note 2: Dual random read means that we are simultaneously performing == == two independent memory accesses at a time. In the case if == == the memory subsystem can't handle multiple outstanding == == requests, dual random read has the same timings as two == == single reads performed one after another. == ========================================================================== block size : single random read / dual random read 1024 : 0.0 ns / 0.0 ns 2048 : 0.0 ns / 0.5 ns 4096 : 0.0 ns / 0.0 ns 8192 : 0.0 ns / 0.5 ns 16384 : 0.0 ns / 0.0 ns 32768 : 0.0 ns / 0.5 ns 65536 : 6.5 ns / 11.4 ns 131072 : 10.5 ns / 16.2 ns 262144 : 15.7 ns / 24.7 ns 524288 : 107.3 ns / 166.7 ns 1048576 : 156.1 ns / 215.9 ns 2097152 : 187.9 ns / 240.9 ns 4194304 : 204.3 ns / 251.5 ns 8388608 : 215.0 ns / 259.8 ns 16777216 : 228.0 ns / 274.9 ns 33554432 : 244.6 ns / 305.7 ns 67108864 : 272.7 ns / 361.9 ns -
I will verify the DRAM chip when I arrive home today.
When I used Cubian, there was an update that increased a voltage due to some stability issues. See: http://cubian.org/2014/07/05/resolve-stability-issue-on-cb2/
Maybe is the same issue we are facing here? I never had this problem with Cubian nor changed the u-boot.
When I arrive home, I will test Cubian with tinymembench so we can check at what speed and voltages Cubian is running.
Edit: I found this: https://github.com/maxnet/a10-meminfo
Looks like it can dump DRAM settings and also works on a20 boards. (Found it re-reading the links linked to the link I posted above.)
-
30 hours running lima-memtester and it survived. No memory errors. That companion cube was making me dizzy already.
I think 432 MHz is pretty stable for CB2.
Just reminding that when it was 480 MHz, it couldn't hold memtester for more than 1 hour.
-
I'm using just memtester, because when I use lima-memtester I get the error:
Please remove 'sunxi_no_mali_mem_reserve' option fromyour kernel command line. Otherwise the mali kerneldriver may be non-functional and actually knock downyour system with some old linux-sunxi kernels.AbortedThe kernel I use is the one at armbian repository (5.20). I did not change the kernel.Strange, because I'm not using a CLI image. There should be memory reservation for GPU, right?For the benchmark I'm using:stress -c 2memtester 100Mopenssl speed -multi 5I will leave it running for today.Edit: It turns out that my boot.src had Mali memory reservation disabled. I dont know why tough. Running lima-memtester now. Tomorrow I'll come back and report. -
I can confirm that 432MHz is stable for Cubieboard 2.
My cubieboard 2 is doing a stress test now and it's stable. The test is already running for 5 hours and I will leave it running for today.When it was 480 MHz, the stress test failed in 1 hour.
I used 432 MHz instead of 384 MHz because of this topic: https://groups.google.com/forum/#!topic/cubieboard/9WMBFAL7JBE
I will upload my u-boot here if anyone is interested. -
I'm cloning the u-boot-source from https://github.com/linux-sunxi/u-boot-sunxi(sunxi branch) and I have no Idea where I need to change the clock value. Tried to read the documentation, but without success. Could anyone help me? Thank you!
-
What file do I change the DRAM speed? I will test 384MHz on my cubieboard 2 too. I know how to compile U-Boot.
-
I have this same exact problem with cubieboard 2. The HDD that it's connected on its usb still spinning, the lan port leds are blinking and the red led from pmu is lit up, but the other two leds are turned off and I have no response from it. Tried to connect a monitor and a keybord but it did not work.
This error occurs once/twice a week.
-
The board did not boot after compiling uboot either from Igor source and phelum source. I solved it by downgrading uboot to version 5.00 in synaptic package manager.
Edit: Nope. Problem still here even with 5.0. Almost giving up
-
Thank you Igor! I'll try to compile it today. I will try to use the cubieboard to compile it too, since I also don't have linux on my computer like zeppa.
I just need to add the line you mentioned anywhere at configs/Cubieboard_defconfig file.
-
Hello! I have a cubieboard 2 and I have the same problem. If I remove the 5VDC cable and wait a little while after inserting it again, my cubieboard 2 shutdown at starting kernel message. If I insert my cubianX sdcard, boot, shutdown the cubieboard2, remove the cubianX sdcard and insert armbian sdcard, my cubieboard2 boots normaly.
I tried to use Phelum U-boot, but without success.
Can anyone help me?
Edit: I'm also using legacy kernel.
Strange connection issue
in Allwinner sunxi
Posted
Yeah... looks like network manager was the culprit. I just disabled it and no problems anymore.
https://wiki.debian.org/NetworkManager