• 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

Ah ok, libretech-cc is Le Potato, S905X, I think you need to use gxb-200  gxb_p201_v1 to start, and probably look at friendlyArm's code to see if their config can just be moved over and adjusted.  Let me take a quick look around.

 

[edit]

 

Can anyone attest to the FriendlyArm Elec u-boot having or not having proper EXT4 support?  if it can handle the EXT4, then just use their repo https://github.com/friendlyarm/u-boot/tree/nanopi-k2-v2015.01

 

Commit where they added the board

 

[edit 2]

 

Try this and show me where it fails.  If it doesn't fail I'm buying lottery tickets.  Also remember you need a boot script with the right device tree, I'm sure meson_gxbb_p201.dtb in mainline would work.

 

u-boot-k2.tar.gz

Share this post


Link to post
Share on other sites

For my image write to SD, try to use this option. File u-boot.bin is generally used to write to eMMC, to record on the SD card need u-boot.bin.sd.bin

 

dd if=u-boot.bin.sd.bin of=your_SD  conv=fsync bs=1 count=442

dd if=u-boot.bin.sd.bin of=yor_SD conv=fsync bs=512 skip=1 seek=1

Share this post


Link to post
Share on other sites

I've also tried balbes today's image, fused the newly compiled u-boot, tweak image/ramdisk to match its filenames accordingly, booted but still stop at "starting kernel" ...

 

(I will take a break now, since I'm pulling too many of my hairs)

Share this post


Link to post
Share on other sites

Check out what dtb use. Usually when this message cause stay in the not correct dtb file. You need to try all the files from the image with the name gxbb*. Yet there may be no output to the console UART, if you use the script s905_autoscript with no proper setting on the console at the command prompt. For the core 4.x need ttyAML0 for kernel 3.14 - ttyS0.

Share this post


Link to post
Share on other sites

Thanks @balbes150 for the hint !

It was really using the ttyS0 instead of the ttyAML0 ...

At the prompt of this u-boot compiled with https://github.com/friendlyarm/u-boot/tree/nanopi-k2-v2015.01  , I've manually changed it and see that it booted further.

I've than noticed that the kernel didn't succeeded to mount the ROOTFS, so I've added "rootwait rootfstype=ext4" to my manual command.

For a permanent change of ttyAML0, I've done it in board/amlogic/configs/nanopi-k2.h, but it seems to be overwritten and keep getting back to ttyS0, although a "strings fip/u-boot.bin.sd.bin" reveal that my change is actually present.

Any hints ?

Also, is that u-boot is the same as Mainline where it should execute a boot.scr ? I'm not seeing any on the current image.

 

Share this post


Link to post
Share on other sites

For the sake of completeness, here is the u-boot SD bin to try.  If we're going to start supporting Amlogic boards, we're going to have to figure out how to group them bootloader wise, right now it's anarchy.  Since Armbian uses EXT4 and bootscripts, and none of the vendor images do, it makes U-boot that much bigger of an issue.

 

u-boot.bin.sd.tar.gz

 

This image (if it works) expects /boot/boot.scr to exist and tell it about the bootargs, the dtb, etc just like the "le potato" image I linked earlier.  It also expects an EXT4 filesystem.

 

I had to use rootwait as well, and between 3.x and 4.x the SD/EMMC numbers switched in the kernel, so the boot parameters had to be adjusted accordingly.

Share this post


Link to post
Share on other sites

@TonyMac32 , I will try you u-boot tomorrow and find what are behaviour differences ...

Initially, I wished to have Armbian nanopi-k2.wip working as I did few months ago for OPiPC2 with the help of André and Zador with their patches for FIT/ATF, but the AmLogic u-boot looks really different ... Is FIP almost equivalent to FIT ?

So, I doubt I will be able to automate nanopi-k2.wip builds soon, since I even have to manually issued u-boot command, but at least I've got this kernel booted ...

 

Share this post


Link to post
Share on other sites

Cool, let me know.  I didn't really do anything different with the blob you have than is in the one for "Le Potato", so honestly, with all the device numbers/dtb's/ and boot scripts sorted out it should be possible once the first couple hurdles are cleared.

 

Now, I haven't spent much time with it, however the Odroid-C2 is more or less the same basic board.  By swapping out the "bl" files you should be able to do a mainline build with it. (hypothetical on my part, but I'd be surprised if it wasn't being worked on already)

 

 

Share this post


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

For a permanent change of ttyAML0, I've done it in board/amlogic/configs/nanopi-k2.h, but it seems to be overwritten and keep getting back to ttyS0, although a "strings fip/u-boot.bin.sd.bin" reveal that my change is actually present.

Any hints ?

Answering to myself : stupid me ! the u-boot default args are overwritten by "saved" args, so I've done them manually again but I had to "saveenv" to keep them ...

Share this post


Link to post
Share on other sites
17 hours ago, TonyMac32 said:

This image (if it works) expects /boot/boot.scr to exist and tell it about the bootargs, the dtb, etc just like the "le potato" image I linked earlier.  It also expects an EXT4 filesystem.

 

@TonyMac32 This one is working too, after creating a boot.scr.

The only strange thing I seen is that "saveenv" isn't working, but it is not a big issue, since boot.scr is doing all the things.

gxb_p201_v1#saveenv
Saving Environment to aml-storage...
emmc/sd response timeout, cmd8, status=0x3ff2800
emmc/sd response timeout, cmd55, status=0x3ff2800
emmc/sd response timeout, cmd1, status=0x3ff2800
MMC init failed

 

Share this post


Link to post
Share on other sites

Cool.  I did not change anything else besides adding the script to see if it would work.  I will have a K2 on the way shortly so we can possibly sort this out more cleanly.  Now, to understand why the S905 likes the SD image blob and the S905X will work from the eMMC blob...

Share this post


Link to post
Share on other sites

I wished to have the AP6212 WiFi working on my NanoPi-K2 !

BTW, it is a AP6212 Non-A ...

So, at first it didn't work. After investigation and few tries, I figured out that a another firmware was needed :

 

as discuss by Hans back in June https://patchwork.kernel.org/patch/9791523/

 

http://jwrdegoede.danny.cz/brcm-firmware/brcmfmac43430a0-sdio.bin.7.10.1.244.ucode940.1020

 to be rename as brcmfmac43430a0-sdio.bin

http://jwrdegoede.danny.cz/brcm-firmware/brcmfmac43430a0-sdio.txt.jumper-ezpad-mini3

 to be rename as brcmfmac43430a0-sdio.txt

 

Hans patch is already merged in 4.13...

 

Share this post


Link to post
Share on other sites
On 22.8.2017 at 4:46 PM, martinayotte said:

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

It is fun to look back how the community didn't let you to give up. And now you have a running SBC more to play with :D and not even Allwinner

Share this post


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

 

And the question is: BroadPwn fixed or not?

 

Are you able to play with the files from http://kaiser-edv.de/tmp/NumpU4/brcmfmac43430-sdio-broadpwn-fix.tar with your AP6212 rev0 and report back?

Share this post


Link to post
Share on other sites

Unfortunately, the http://kaiser-edv.de/tmp/NumpU4/brcmfmac43430-sdio-broadpwn-fix.tar files don't seems to work.

 

I'm getting timeout and refuse to register its interface :

[   15.660083] brcmfmac: brcmf_fw_map_chip_to_name: using brcm/brcmfmac43430a0-sdio.bin for chip 0x00a9a6(43430) rev 0x000000
[   16.840982] brcmfmac: brcmf_sdio_htclk: HT Avail timeout (1000000): clkctl 0x50
[   17.868309] brcmfmac: brcmf_sdio_htclk: HT Avail timeout (1000000): clkctl 0x50
[   18.872331] brcmfmac: brcmf_sdio_htclk: HT Avail timeout (1000000): clkctl 0x50

Replacing back the old A0 firmware files, and it works again :

[    7.900828] brcmfmac: F1 signature read @0x18000000=0x1530a9a6
[    7.903201] brcmfmac: brcmf_fw_map_chip_to_name: using brcm/brcmfmac43430a0-sdio.bin for chip 0x00a9a6(43430) rev 0x000000
[    7.903368] usbcore: registered new interface driver brcmfmac
[    8.180503] brcmfmac: brcmf_c_preinit_dcmds: Firmware version = wl0: Jul  1 2016 18:02:40 version 7.10.1 (A0 Station/P2P feature) FWID 01-bae8afee

 

Share this post


Link to post
Share on other sites

Followed Balbes150's advice using u-boot.bin.sd.bin for my blob source, and switched the dd commands.  @martinayotte you should be able to build a booting Armbian right from the build script.  I've also added the K2 to the u-boot repo I'm keeping.  

 

So far Mainline (4.14) isn't giving me an HDMI display for the K2 I'll check my kernel config.  3.14 has "static", I assume this has to do with not shutting off the other framebuffer and I'll work with that later, as well as build a 4.13 "next" image. (More heavily patched).  

 

Very much WIP

 

[edit]  The Mainline device tree for the K2 is very skeletal, we just need to flesh out the things we know, drivers exist for the hardware already.

 

[edit] Added HDMI to nanopi-k2 dts, also seeing static like on 3.14, however functional desktop otherwise.

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.