wildcat_paris

It should work without installing something. For some reason the keyboard and mouse are not detected.
Do they work on another computer? Check your USB cables and USB-hub if you use any.

Thx, for whatever reasons simply exchanging u-boot with 2016.05 containing this patch didn't work. I re-created a whole new image with
./compile.sh \ KERNEL_ONLY=no \ BOARD=lime2 \ PROGRESS_DISPLAY=plain \ RELEASE=xenial \ EXTENDED_DEBOOTSTRAP=yes \ COMPRESS_OUTPUTIMAGE=no \ FIXED_IMAGE_SIZE=4096 \ ROOTFS_TYPE=btrfs and this worked. Ethernet performance still isn't optimal but that's ok since the Lime2 will be playing webserver at a customer's location and more than 200 Mbits/sec aren't necessary. http://sprunge.us/eBZI
 
So thinking about our user base... how to proceed with Lime2? If I understood correctly the patch now prevents negotiation of a direct network connection between two hosts and only connections with a switch in between will work. I would suppose that's the 99 percent use case of Lime2 users therefore why not enabling this patch by default?

Thanks a lot ZADOR !
 
I modify to have only uboot v2016-05
 
And now for u-boot it's ok .... But I already have my 1st problem ......I work on ununtu 16LTS  8GO ram Two core intel 
 
Uboot  and kernel compile ok but when armbian want to download debootstrap file i have an error ... I dont know if it's my computer or anything else ....an update of my computer ?  server down ?
 

Why don't you look at original Loboris settings then? Nobody here is comfortable to give you instructions how to shorten your board life. After all, a lot of time was spent to convince everyone that 1.6 GHz @ 1.5V hurts the chip.

Overclocking H3 based boards is an option for users who believe in rationalism and not for users who believe in marketing bullshit. So @tkaiser simply protects this forum from users that would set their boards to 1.6GHz instead of 1.2GHz just because 1.6 is higher than 1.2, and then whine that "my board doesn't work anymore", "armbian is unstable" and "armbian sucks".

Open source was a marketing gag by IBM trying to usurp the professional work of the free software world. The Armbian team does a stellar professional job to convert some random heaps of assorted hardware into useful working systems. There is a lot of dedication, pride and hard work to put some basic sanity into this tinker world.
 
True FREEDOM in software is complete CONTROL.   Don't blame professionals for doing their job. Feel free to run your car off the cliff.

Just a funny note: SinoVoip announced yesterday an own A64 board: BPi M64. They took kernel/u-boot/device-tree settings from longsleep/linux-sunxi community and prepared their most recent OS images already for BPi M64 (providing the necessary stuff on the FAT partition and being able to overwrite the bootloader with their bpi-bootsel command).
 
Since at the moment they didn't alter anything regarding device-tree stuff (it's all 100 percent copy&paste from Pine64+) I simply tried it out and tested their so called 'Raspbian Lite' OS image on Pine64+ (boot log):
root@bpi-iot-ros-ai:/tmp# sysbench --test=cpu --cpu-max-prime=10000 run --num-threads=4 sysbench 0.4.12: multi-threaded system evaluation benchmark Running the test with following options: Number of threads: 4 Doing CPU performance benchmark Threads started! Done. Maximum prime number checked in CPU test: 10000 Test execution summary: total time: 52.2640s total number of events: 10000 total time taken by event execution: 208.9829 per-request statistics: min: 18.97ms avg: 20.90ms max: 61.86ms approx. 95 percentile: 21.83ms Threads fairness: events (avg/stddev): 2500.0000/5.05 execution time (avg/stddev): 52.2457/0.01 root@bpi-iot-ros-ai:/tmp# bpi-hw bpi-m64 root@bpi-iot-ros-ai:/tmp# cat /etc/os-release PRETTY_NAME="Raspbian GNU/Linux 8 (jessie)" NAME="Raspbian GNU/Linux" VERSION_ID="8" VERSION="8 (jessie)" ID=raspbian ID_LIKE=debian HOME_URL="http://www.raspbian.org/" SUPPORT_URL="http://www.raspbian.org/RaspbianForums" BUG_REPORT_URL="http://www.raspbian.org/RaspbianBugs" Same hardware. Using a good OS image (making use of ARMv8 instruction set) the benchmark takes 3.2 seconds, 'Team BPi' manages to provide an OS image where the same benchmark takes 16 times longer: 52 seconds (Armbian running on an Orange Pi Plus 2E takes less than 40 seconds). Then rootfs is nearly full, u-boot and kernel are already outdated and of course kernel update doesn't work since 'Team BPi' was so clever to read the necessary files from an unusual location and so on... So you already know what to expect when you have to rely on their software/support

This is the log with boot fail:
 
 
This is the log of boot from internal flash (with manualy forced shutdown after full start):
 
 
 
And this is serial boot log when i boot it as described - boot legacy from sd after "boot without sd":
 
 

New u-boot issue will be fixed (or u-boot version will be reverted to v2016.05). Meanwhile you can try setting
BOOTBRANCH="v2016.05" in userpatches/lib.config
 
 
It can be done manually by disabling update procedures and building of additional applications and drivers.

Rev 1.0 (resolution should be high enough to spot details): http://linux-sunxi.org/Banana_Pi_M2%2B#Pictures
 
And no, I won't spend any more time with Foxconn/SinoVoip products. They simply don't get it and we here at Armbian should also think about stopping to support all of their products except of the real Banana Pi [TM]. It's both an insanely waste of time and also a wrong signal to our users.
 
Just as a little example: 'Team BPi' produced for each and every BPi that came after the first A20 based fake videos showing features that didn't work (at that time), especially regarding 'GPU acceleration' and 'HW video acceleration'. When they came out with the H3 based M2+ where all this stuff already worked (since community did such a great job over at linux-sunxi and also in Orange Pi forums) they were still busy showing fake videos (nearly statical manga video stuff as proof that 'HW acceleration' would work) instead of using any of the advanced OS distros for H3 boards and demonstrating that it really works using appropriate software.
 
They simply don't get it, just look through their forums. But on the other hand they don't need to improve anything since they can sell all this incompatible crap under the Banana brand and therefore constantly new clueless people buy their products just to realize later that nothings works (as expected), then use these electronics as a paperweight and disappear from the forums since none of their questions got answered. Then the next bunch of fooled customers appears, complains, does not get their questions answered and the whole thing repeats again and again.  

I went to "allwinner H3" section and I found two threads about camera, on the first page:
 
http://forum.armbian.com/index.php/topic/957-orange-pi-c%C3%A2mera-gc2035-works-fine-with-v4l2-applications/
 
http://forum.armbian.com/index.php/topic/1213-ov5640-camera-with-orange-pi/

Since I struggled and now it works here is the explanation
 
sudo nano /etc/modules
 
add
snd-bcm2835
i2c-dev
  sudo apt-get install i2c-tools
sudo apt-get install python-smbus
  reboot   wget https://bitbucket.org/MattHawkinsUK/rpispy-misc/raw/master/python/lcd_i2c.py
  sudo  i2cdetect -y 1 or  sudo  i2cdetect -y 0 device should  be identified on 0x27   Run the script  

Try http://docs.armbian.com/User-Guide_Getting-Started/

Every time I check entropy it is a 4 digit number, but sometimes is less than 4096, one time was 1200 something. I never even knew 'entropy' was part of the kernel. I thought it was space and time but that's another forum ;]

/etc/network/interfaces 
auto eth0
allow-hotplug eth0   
 
auto wlan0
allow-hotplug wlan0
 
You might get some ideas from http://forum.armbian.com/index.php/topic/1237-tutorial-opi-one-wireless-success/
Check your configuration and retry. Good luck.

Well, the results aren't impressive (way slower than EVO/EVO+ and Pro we already tested) and it's somewhat useless to measure when information about the amount of background activity is not available as well as cpufreq settings. That's why I provided an own test image in the first place... to be able to compare different hardware afterwards since every test happened with identical settings.
 
New results: neither SD card nor NAND/eMMC but an USB stick: "Samsung Memory Fit USB Flash Drive Speicherstick 128GB" bought for approx 45 bucks for a customer to double the storage capacity of his MacBook:
 

 
Performance connected to the MacBook using USB 3.0 is quite ok, connected to an Orange Pi PC Plus (USB 2.0, performance cpufreq governor, ext4 without further tuning) it's not that great:
random random kB reclen write rewrite read reread read write 102400 4 6719 4639 7289 7327 3325 673 102400 16 8865 10110 17630 13126 9332 1738 102400 512 15794 5296 30224 29691 20380 7460 102400 1024 17655 21927 23763 30117 29757 10017 102400 16384 29651 18520 31263 24585 31983 13342 Device info according to lsusb:
 
 
 
But since the device is really small and other USB sticks I tested recently (Kingston, Verbatim and SONY) were magnitudes slower I decided to post results here in case anyone is searching for a low power solution requiring minimum space to add 128GB to his SBC.

BTW: Just looked through FriendlyARM's github repo. They lowered DRAM clockspeed for NanoPi M1 (from the 624 MHz we used all the time since we do not trust in the 672 MHz -- Allwinner's defaults) and on the NEO it's even worse. This new board has only a single bank memory implementation (so no 32-bit memory accesses) and they clock it with just 432 MHz.
 
It seems in case we want to support this board OS images for Nano Pi M1 won't suffice due to different DRAM. I adopted FriendlyARM's fex file to our 'standards' (THS/throttling and LED handling) and added it to the repo: https://github.com/igorpecovnik/lib/blob/master/config/fex/nanopineo.fex

Actually several tasks are executed at this point: 
Creating SSH keys Creating swap file Adjusting swap related parameters Tweaking ramlog if it is installed There should be some messages in /var/log/armhwinfo.log regarding some steps.
 
Are you sure that it completely hangs? Can you switch to other TTYs (i.e. to tty2 by pressing Ctrl-Alt-F2) and login from there if a prompt is available?

I still have the same problem on some SD cards (even with network connected).
 
Here is another lead I have not time yet to follow:
 
http://blog.jamesrhall.com/2014/04/ubuntu-server-1404-fun.html
 
Apparently, the kernel switches to a video mode that is not seen through serial link. So adding nomodeset could avoid this blocking.
 
 
I am interested in the link of the other thread you talked about

It seems the QA person who tested your board before shipping has very BIG fingers to get this kind of issue (fitting a SD card to see if it boots is part of QA testing) Orange boards are usually of a decent quality and design.
 
Either you can ask for a board exchange or you can live with this bothering but quite "minor" contact issue
 
The nice thing, the Board boots, lucky. I guess you appreciate your board even more now

That's throttling! What else?!
 
H3 reports higher temperature and our settings limit cpufreq automatically in this situation. So you already see that the kernel reduces clockspeeds when starting to heat up so you know that throttling is working. Why do you advice others to fiddle around with settings then? That's what throttling is made for: reducing clockspeeds when necessary (compare stress or running benchmarks with normal use cases: most of the times we deal with single threaded workloads and therefore reducing maximum clockspeed by default is simply dumb as hell -- allow the max and let throttling do the job!)

So what? Cross-compiling on a 64-bit Ubuntu system is what we do all the times for all our 32-bit kernels / OS images. Doesn't mean anything whether you can use a 64-bit host or not. NanoPi M3 has only a 32-bit kernel which is bad.
 
The rest of your posting (thermal stuff) I didn't understand. Fortunately others provide information how to read-out temperatures and how horribly this M3 will overheat without a HUGE heatsink + ventilation: http://climbers.net/sbc/40-core-arm-cluster-nanopc-t3/

MIPSbian ...

Thank you,
 
I think I found why it did not work: without Ethernet cable connected, the boot process hangs. With the Ethernet cable connected, it works.
 
So I think that the random pool was not enough random without the cable connection.
 
So good news: my SD card is fine !

Hello,
 
actually it was not the first time the upgrade failed on this board:
- upgrade 5.11 to 5.15 -> returned successfull
- reboot
- at boot system can not find file: sun6i-a31s-bananapi-m2.dtb
(file sun6i-a31s-sinovoip-bpi-m2.dtb for BPi M2 is available)
- fixed it by linking to the existing device tree blob sun6i-a31s-sinovoip-bpi-m2.dtb
- reboot again
- no network
(my /etc/network/interfaces has been set to armbian default, same as /etc/network/interfaces.default, this happened the first time)
fixed it again by setting the correct content
 
I don't know if the upgrade process is the problem or if there is something messed up on my board...
 
Now everything is working again... But I guess it will be the same next time...
 
regards
Holsteiner