• Before reporting problems with your board running Armbian, check the following:

    • 1. Check power supply, check SD card and check other people experiences   06/23/17

      Power supply issues are one of the three biggest issues you'll face when starting with Single Board Computers (SBCs). SD card issues, whether fake or faulty, are another and issues resulting from poor board design is the other common issues you can encounter.   Power supply issues can be tricky. You might have a noisy power supply that works with one board because it has extra filtering, but won't work with another. Or you're using that cheap phone charger because your board has a microUSB connector, and it is either erratic, or doesn't start up, or even becomes the cause of some SD card issues.    Some tips to avoid the most common causes of problems reported:   Don't power via micro USB  - unless you have optimised your setup for low power requirements. Micro USB is great for mobile phones because they are simply charging a battery. It's bad for SBCs. Yes, it does work for a lot of people, but it also causes more problems and headaches over time than it is worth, unless you know exactly what you are doing. If you have a barrel jack power connector on your SBC, use it instead! If there is an option for powering via header connections, use that option!
        Don't use mobile phone chargers. They might be convenient and cheap, but this is because they are meant for charging phones, not powering your SBC which has particular power requirements.
        When you are evaluating a power supply, make sure you run some stress tests on your system to ensure that it will not cause issues down the path.   (Micro) SD card issues can be sneaky. They might appear right at the start causing strange boot and login errors, or they might cause problems over time. It is best to run a test on any new SD card you use, to ensure that it really is what it is, and to ensure that isn't faulty. Armbian provides you a simple way to do this   --   armbianmonitor -c /path/to/device/to/test  
    • 2. Make sure to collect and provide all necessary information   06/24/17

      We can only help if you provide quality information for us to work with. All stable images from the download section are tested, most stable upgrades are tested and we have tens of thousands of users. Even with regular and extensive testings, bugs sometimes do slip through. This is a voluntary support service and is unrelated to board makers, and is not obligated to provide you any answers. Repeated asking the same questions because you're not happy with the answers will result in you being ignored.

      Before you post a question, use the forum search as someone else might have already had the same problem and resolved it. And make sure you've read the Armbian documentation. If you still haven't found an answer, make sure you include the following in your post:   1. Logs when you can boot the board: armbianmonitor -u (paste URL to your forum post)   2. If your board does not boot, provide a log from serial console or at least make a picture, where it stops.   3. Describe the problem the best you can and provide all necessary info that we can reproduce the problem. We are not clairvoyant or mind readers. Please describe your setup as best as possible so we know what your operating environment is like.     We will not help in cases you are not using stable official Armbian builds, you have a problem with 3rd party hardware or reported problem would not be able to reproduced.

Trying to boot NanoPi-K2
0

46 posts in this topic

Recommended Posts

I have a NanoPi-K2 sitting in the dust since awhile.

I decided to try some images from @balbes150, such as Armbian_5.32_S9xxx_Ubuntu_xenial_3.14.29_server_20170820.img.xz or even some other such Armbian_5.27_S9xxx_Debian_jessie_4.13.0-next-20170731+_server.img.xz, but none of them is even starting to load u-boot ... :wacko::(

 

It is only producing such output on debug serial :

 

GXBB:BL1:08dafd:0a8993;FEAT:EDFC318C;POC:3;RCY:0;EMMC:800;NAND:81;SD:0;READ:0;CHK:F3;USB:8;LOOP:1;EMMC:800;NAND:81;SD:0;READ:0;CHK:F3;USB:8;LOOP:2;EMMC:800;NAND:81;SD:0;READ:0;CHK:F3;USB:8;

I don't know much about Amlogic, what I'm missing ?

 

Share this post


Link to post
Share on other sites

AFAIK most Amlogic devices supported by @balbes150 are TV boxes with eMMC storage and on Amlogic devices eMMC has higher boot priority compared to SD. So most likely those images don't have u-boot at all and rely on stock u-boot in eMMC. You can try comparing official FriendlyELEC images and these images in a hex editor.

Share this post


Link to post
Share on other sites

Ah ! Ok !

That would means that I've to overwrite the u-boot with one that is working ?

I will try that, I've just downloaded this one : nanopi-k2_ubuntu_core_xenial-20170718.img.zip

Share this post


Link to post
Share on other sites

Grrrrr ! :angry:

 

Even this FriendlyELEC nanopi-k2_ubuntu_core_xenial-20170718.img.zip image just enter in a boot loop for awhile, but after several trys, I've finally got the prompt ...

 

Thanks, Zador for the hints, I will take a lot at that !

Unfortunately, I think it will take a lot of efforts ...

 

EDIT : Grrrrr ! :angry: After a reboot, the boot loop came back again ...

Share this post


Link to post
Share on other sites
6 minutes ago, zador.blood.stained said:

And since it is S905 based it may be possible to rely on pure mainline u-boot using Odroid C2 config with some patches.


Yes, that is worth trying ... but u-boot needs to be pushed in the ass first :) 

Share this post


Link to post
Share on other sites
5 minutes ago, Igor said:

Yes, that is worth trying ... but u-boot needs to be pushed in the ass first :) 

You mean something like this? https://lists.denx.de/pipermail/u-boot/2017-May/291439.html

Since it's a new device we can experiment all we want (compared to XU4 where unfortunately we already have mainline based images marked as "stable" with the legacy u-boot). Also since I don't see mainline images for C2 marked as "stable" we can probably use the mainline u-boot for C2 next/dev branches too.

Share this post


Link to post
Share on other sites

@zador.blood.stained hit it on the head, there is no u-boot in balbes images.

 

If you still get the loop with a custom image, the u-boot blob isn't being written to the correct position on the card, so the first stage bootloader isn't seeing it. Now I don't know why you might be able to get to a u-boot prompt "after a while".  That doesn't sound healthy.

 

I have the u-boot source from the June Amlogic sources, what board is the K2 most like, maybe I can build a blob for you that will work.

Share this post


Link to post
Share on other sites
40 minutes ago, TonyMac32 said:

If you still get the loop with a custom image, the u-boot blob isn't being written to the correct position on the card, so the first stage bootloader isn't seeing it. Now I don't know why you might be able to get to a u-boot prompt "after a while".  That doesn't sound healthy

The boot loop wasn't with balbes image, but with FriendlyELEC image ... So, not stable enough, I decided to build a C2, and will report back if it is working better.

 

Share this post


Link to post
Share on other sites
13 hours ago, zador.blood.stained said:

AFAIK most Amlogic devices supported by @balbes150 are TV boxes with eMMC storage and on Amlogic devices eMMC has higher boot priority compared to SD. So most likely those images don't have u-boot at all and rely on stock u-boot in eMMC. You can try comparing official FriendlyELEC images and these images in a hex editor.

 

13 hours ago, martinayotte said:

I decided to try some images from @balbes150, such as Armbian_

Further in the subject have the right information on how to start Armbian on this model.

 

Share this post


Link to post
Share on other sites

Thanks, @balbes150 !

Using @kicker22004 patches, I got the Armbian_5.32_S9xxx_Ubuntu_xenial_3.14.29_server_20170820.img.xz image booting ! ;)

But unfortunately, on-board WiFi not detected ...

Trying some Mainline images didn't lead to some success, staying stuck at "Starting kernel ..." !

 

EDIT : even the Armbian_5.32_S9xxx_Ubuntu_xenial_3.14.29_server_20170820.img.xz start doing some reboot loop now. I think my board is simply defective, FriendlyArm maybe simply send me this sample from "rejected" one ...

(It will return in the drawer to collect dust :angry:)

 

Share this post


Link to post
Share on other sites

Unfortunately, with Armbian_5.32_S9xxx_Ubuntu_xenial_3.14.29_server_20170820.img.xz, there is no modules for AP6212, either it is part of kernel or not present at all, although the /lib/firmware/ap6212 is present.

"dmesg" doesn't reveal much.

Anyway, with the intermittent reboots and boot loops occurring in the middle of some apt-get I had this morning, I'm convince that this board is probably defective.

 

Share this post


Link to post
Share on other sites
1 hour ago, martinayotte said:

intermittent reboots

I had once a bad power connector (barrel jack) and it took me a while to find out it was this and not the software that forced the reboots :huh:

 

Doesn't this board have to ways to power it ?

Share this post


Link to post
Share on other sites
25 minutes ago, Tido said:

Doesn't this board have to ways to power it ?

Since the center pin of the barrel is bigger than the one from OPi, I didn't have any jack for it, so I've powered the board directly from 5V pin of the header.

 

BTW, I've finally recover the bad apt-get without reboot, but I don't know when things will go bad again, maybe it is a bad DRAM and crash when hitting bad region.

 

Share this post


Link to post
Share on other sites
5 hours ago, martinayotte said:

Since the center pin of the barrel is bigger than the one from OPi, I didn't have any jack for it, so I've powered the board directly from 5V pin of the header.

 

BTW, I've finally recover the bad apt-get without reboot, but I don't know when things will go bad again, maybe it is a bad DRAM and crash when hitting bad region.

 

You can test the RAM by installing the memtester package and run: 

sudo memtester 1024 5

This should allocate 1024MB of memory, and repeat the test 5 times.

Share this post


Link to post
Share on other sites
10 hours ago, martinayotte said:

Unfortunately, with Armbian_5.32_S9xxx_Ubuntu_xenial_3.14.29_server_20170820.img.xz, there is no modules for AP6212, either it is part of kernel or not present at all, although the /lib/firmware/ap6212 is present.

"dmesg" doesn't reveal much.

Anyway, with the intermittent reboots and boot loops occurring in the middle of some apt-get I had this morning, I'm convince that this board is probably defective.

 

modprobe dhd

 

or

 

modprobe wifi_dummy

 

 

PS

In order to better understand the features of these images Armbian (they have a number of differences from the official versions), I recommend to read the latest pages of the topic.

 

 

TonyMac32 likes this

Share this post


Link to post
Share on other sites

Wishing to having a Mainline running on this NanoPi-K2, I gave second tried using Armbian_5.32_S9xxx_Ubuntu_xenial_4.13.0-rc7-next-20170901_mate.img.xz and then dts.img copied and ran ./fusing.sh /dev/sdx.

Still no chance : still stuck at "Starting kernel ...".

About trying using a OrdoidC2 build, but they have some protection in their u-boot/bl1.bin.hardkernel, producing the following error :

 

***** Warning!! *****************************************************
* This board have not been autorized or product keys are not valid. *
* Please contact with Hardkernel or your distributor                *
*********************************************************************

 

Share this post


Link to post
Share on other sites

Mainline built with Armbian runs on Le Potato with no issues, have you tried to build it yourself?  I did have to play with the boot script due to some device names moving around.  The nanopi is basically a Meson-gxbb, correct?

Share this post


Link to post
Share on other sites

Do you means that you've used a OdroidC2 build to run on LePotato and you didn't face the protection I've mentioned ?

I will try to build a LePotato image and try to boot it on K2 ... Thanks !

 

EDIT : Unfortunately, a LePotato image doesn't work, it produce the same boot loop I've originally mentioned few weeks ago.

GXBB:BL1:08dafd:0a8993;FEAT:EDFC318C;POC:3;RCY:0;EMMC:800;NAND:81;SD:0;READ:0;CHK:F3;USB:8;LOOP:1;EMMC:800;NAND:81;SD:0;READ:0;CHK:F3;USB:8;LOOP:2;EMMC:800;NAND:81;SD:0;READ:0;CHK:F3;USB:8;

And of course, fusing the crappy k2uboot.bin was waste of time, because it require a FAT boot partition.

I think I'm missing a lot of knowledge on those AmLogic (I'm too fluent with AllWinner).

 

Share this post


Link to post
Share on other sites

Right, sorry I was vague.  The bootloader is the difference (s905x versus the s905), I don't have a K2 to experiment with to build it, but if you clone  https://github.com/Tonymac32/Amlogic-u-boot

 

And get the toolchain it calls out in the makefile (I haven't tried with others, I stuck with what worked since I didn't want to get lost in the woods), you should be able to modify the proper board the K2 is most similar to to pull the boot.scr from ext4 (example)

 

Make sure EXT4 is enabled

Makes sure ext4 commands are enabled

 

And, using @balbes150's excellent work as a guide, set it up to look for boot script on various devices.

 

The new "file loader" command:  bloader

 

going to the root of the working directory run "./mk <boardname>", go to the "fip" directory, and burn the "u-boot.bin" to SD: 

dd if=u-boot.bin of=<your SD Card> bs=512 seek=1 conv=fsync

Le Potato Boot script (reference)

 

Device numbers may vary.  At present the boot blob I made for Le Potato successfully handles EXT4 without complaint.  There are some grumblings from routines I haven't squashed that are looking for early dtb loading for 3.x kernels using FAT, but that won't bother mainline.

Share this post


Link to post
Share on other sites

Thanks @TonyMac32 !

 

Unfortunately, still doesn't work ! Boot loop mentioned above still there an u-boot never started ... :(

You u-boot build successfully, I've only had to change the CROSS_COMPILER path in the Makefile. The "make sure" you've mentioned were already present, so I've "dd" the resulting "u-boot.bin".

It looks like it doesn't even load that u-boot. What those means exectly ?

GXBB:BL1:08dafd:0a8993;FEAT:EDFC318C;POC:3;RCY:0;EMMC:800;NAND:81;SD:0;READ:0;CHK:F3;USB:8;LOOP:1;

 

Some thing look strange to me : doing "strings u-boot.bin" doesn't show any default variables like it used too with any other u-boot.

 

EDIT : btw, are you sure about "bs=512 seek=1" ? It seems to be pretty low compare to AllWinner where u-boot is usually placed at "bs=1024 seek=8"

Share this post


Link to post
Share on other sites

Yeah, it's not finding the bootloader.  

Hmm, which board did you use as template?  There is an offset of some sort between the two, when using an S905 image on S905X you get the same result.  

 

Another good example of needing all the cousin boards, I'll have to get my hands on a K2 and a C2.  

 

Yes, that is the dd command, I've been using it almost daily.  ;-) I'll make sure the S905 is the same, why it wouldn't be I don't know

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

0

  • Support the project

    We need your help to stay focused on the project.

    Choose the amount and currency you would like to donate in below.