I've received my NanoPC. At this stage there is very little information regarding custom Linux compilations. Seems like most boards using this processor tend to use Android. I like my kernel and OS lean and fast. Anyways. I've been using Oselas on my Mini2440 and started compiling Yocto for my my NanoPC. Would it be possible to configure Oselas for the NanoPC (armv7)? Thanks
I'm running a custom built angstrom distribution (based on yocto 1.6) with kernel 3.14 on nanopc-t1 so yes, it's possible. But looking at the (missing) answers here it seems that nanopc owners are on their own...no bootloader sources, no kernel sources, no answers to the most basic questions...
Hi Enrico, May I ask: 1.) What documentation did you use? 2.) What recipe did you use? 3.) What MACHINE type did you use? 4.) How did you create a RAM disk? If possible, please give me as much info as possible to get Angstrom running on my NanoPC. Thank you MC
Hi Enrico, I'm eager to hear from you!? MC
Well I've been looking all over and can't find anything compatible with the NanoPC so I'm assuming you've created your own layer?
Just a shot into the dark: The SoC is the main part, and anything else around it is more or less not very important. So you should be happy to get this machine up and running with a generic recent kernel configured for this SoC. And I think, only the kernel is a critical component here. Not the userland. For userland you can use some ARMv7 compiler to run your own software. And that's why it is not important if you use Yocto, PTXdist or Angstrom. First get your own kernel booting this machine and then you are free to continue like you want.
Hi Juergen, Thank you for the reply. That is exactly my problem, getting my own kernel to work. I do not have a armv7 toolchain (or I do but read on). When I started with my Mini2440, I battled for very long doing custom compilations but then I found ptxdist and Oselas. That helped a lot but at the same time I think it made me stupid and lazy. To avoid having to spend weeks on getting nowhere and just to make things simpler I'm looking at these distro's. I'm scared of downloading a pre-compiled toolchain or even compiling my own toolchain because I've experienced myself how it can go wrong. Maybe I should give it a try again.......??
Hi bluescape, getting an ARMv7 toolchain should not be very difficult. But okay, it's my point of view, because it is my daily job: I'm building one from our toolchain bundle and then I'm ready to work with it. Maybe you will be happy with one of the ready-to-be-use distros. Try to use embedian or similar. But most of the time embedded people need more specific things than a generic distro can provide. At least the kernel is this very specific thing one needs first. That is why binary distros drive me crazy. For my development host as well. My development host bases on "Linux from Scratch". Okay, that is the hard way. But you can learn a lot *how* things are work. After these lessons tools like Yocto or PTXdist are just tools that help you to collect and compile your own software. Nothing more. And these tools are really nothing more. *You* are still the important part, who assembles all the small details, not the machine, not the tool. Happy hacking
Ok, I've managed to compile a working kernel. Now busy with busybox and then the painful part, getting Qt5 working. Will keep you posted.
Bluscape or Enrico, What was the method you used to get your custom working kernel? I've been able to cross-compile a bare bones rootfs that almost works (still working with kinks) with the help of the buildroot utility, if I supply the released QT kernel (zImage) file for superboot and my own rootfs then the device boots, but has a few errors I need to work around. However, I have been completely unsuccessful at getting a custom zImage (tried 3.13, 3.14, and 3.15 rc2) to boot the device. After flashing with Superboot and resetting it simply says "Booting to eMMC" over serial and never launches the kernel (no error messages either). I must be missing something simple.. any help appreciated. Thanks
Hi, Documentation: http://processors.wiki.ti.com/index.php/Creating_a_Root_File_System_for_... http://minidevs.googlecode.com/files/Tiny210-Mini210%20System%20developm... Sources: http://kanebebe.dip.jp/download/Cortex-A9-4412-DVD/ Using the toolchain and kernel from the Sources link. Following TI documentation to compile a custom FS. Cheers MC
Ok, thanks Bluscape. I actually have that linux-3.5 source but I was hoping to get a more recent kernel version to work. Enrico had mentioned he was working on a 3.14. Thanks for the extra documentation, I will definitely go through it. Also, I appreciate the reply! A lot of the NanoPC-T1 threads around here seem to die with open questions.
Hi, Just download the 3.14 kernel and copy the config file from the 3.5 kernel to the 3.14 kernel. The config file will not have all the configurations for the 3.14 kernel but the majority will be the same (you might need to tweak it). Then compile it.
Yup, that's what I've done, several times. I'm sure my zImage is good.. but for some reason superboot won't boot it but will boot the qt zImage. I verified all the right Tiny4412 stuff was selected before compiling too. BTW: Thanks again for the Root FS document.. it helped me solve a few issues on my rootfs.
Ok, I might give it a go at some stage. Will let you know when I've done that. Also keep me posted please. Thanks
Last few things: 1.) Are you cross compiling? Meaning are you selecting the correct toolchain (in the kernel config)? 2.) Do you compile with ARCH=arm (in the kernel make file)?
Yeah, it's all within the same environment that I compile the rootfs which works/executes flawlessly now that I setup the mdev stuff properly from your link. I have a minimal busybox rootfs with lighttpd, dropbear, python and qt libraries. Going to work on getting PyQT working on it as well. Total size so far just under 100MB. Everything works great with the known good kernel. That's my last missing piece. I will say though that I am not using the toolchain from the site.. I am using my own toolchains. I've tried following instructions from Embedded CLFS (manually), which used the musl libc, and then getting lazy with buildroot (which is like your Yocto I think) which uses uclibc. These are my compiler settings within buildroot, I had similar for Embedded CLFS: BR2_ARCH="arm" BR2_ENDIAN="LITTLE" BR2_GCC_TARGET_ARCH="armv7-a" BR2_GCC_TARGET_ABI="aapcs-linux" BR2_GCC_TARGET_CPU="cortex-a9" BR2_GCC_TARGET_FPU="vfpv3-d16" BR2_GCC_TARGET_FLOAT_ABI="softfp" BR2_GCC_TARGET_MODE="arm" BR2_ARM_CPU_HAS_NEON=y
Another useful article: https://github.com/surajx/qemu-arm-linux/wiki/Compile-Linux,-BusyBox-for...
Hi fatalsaint, When BusyBox is compiled it generates a BIN file. What type of image did you create from the BIN file and what tool did you use? Thanks
Did you honor the need for a device tree to configure your recent kernel at runtime? Enable earlyprintk and debug in the kernel and the command line.
Juergen, Thanks for the tip on earlyprintk. Enabling that and DEBUG I now see the problem, but am not entirely sure how to fix it: Superboot-4412 V1.6(20140317) by FriendlyARM Booting from eMMC Uncompressing Linux... done, booting the kernel. Error: unrecognized/unsupported machine ID (r1 = 0x00001200). Available machine support: ID (hex) NAME ffffffff Samsung Exynos4 (Flattened Device Tree) Please check your kernel config and/or bootloader. Research indicates this is a mismatch between the bootloader and the kernel but I'm still trying to figure out where to add the machine ID to support it. Bluscape: I'm not sure I understand your question? When I compiled BusyBox on my own I followed these instructions: http://cross-lfs.org/view/clfs-embedded/arm/final-system/busybox.html Which are very similar to the instructions in the link you provided for creating a rootfs. Basically just a make install to the target directory. Now I'm having buildroot do it for me, but it's doing the same thing - just make && make install to the target directory.
Hi FatalSaint, What bootloader are you using? If you are using the pre-compiled bootloader then the problem is most probably with your kernel compilation but there could still be a discrepancy from the bootloader. If you are using your own bootloader, have you tried booting with the pre-compiled bootloader? I'm sure you've done this but just check: Kernel: ARCH=arm make menuconfig Sytem Type->ARM system type->SAMUNG EXYNOS If it still fails, maybe probe /arch/arm
FatalSaint, the error message means your bootloader still expects a platform aware kernel but the new kernel uses a devicetree for this purpose. Update the bootloader to support device tree or enable the CONFIG_ARM_APPENDED_DTB and append the devicetree manually to your kernel (read the help of the ARM_APPENDED_DTB menu entry how to do so).
Ahh! listen to the voice of experience!
So, is there any guidance on compiling a bootloader that will work with the NanoPC-T1? I have tried the pre-compiled Superboot4412.bin, which is what gave the above error, and have tried the U-Boot compatible image from the Ubuntu release and it gives the same error. I've tried compiling U-boot myself, but of course the NanoPC-T1 isn't supported directly so I'm using board "smdkv310" (ODROID) which is also based on the Exynos4 architecture. It does not appear to be working, however. I get no output with an SD card flashed with my custom u-boot.bin binaries. I will continue to look at CONFIG_ARM_APPENDED_DTB, but I had that already enabled and setup in the kernel that I got that post from. So, still haven't gotten a working kernel. Thanks
Hi FatalSaint, To deviate from the topic. Why do you want to use the latest kernel? I've been down this road before. I wanted to use the latest kernel just because it is the latest and for no other specific reason. I also had difficulty getting it to work. Eventually I decided to stick to what was working and never regret doing that. The kernel was slightly older but it was doing its job and I didn't waste anymore time. Actually I did eventually get it to work just to realize there was a problem with that kernel version (Had some problems with the audio DMA). Unless there is specific features in the latest kernel you would like to use. Note: You spend all that time just to have the latest kernel. Next month there is another version, then what? Do you spend a lot of time getting that to work too? The kernel provided by friendlyarm is known to work with all the peripherals on the NanoPC. Maybe have a look at this article: http://www.informit.com/articles/article.aspx?p=1647051&seqNum=5 It seems like you need two images, one for the kernel and one for the DTB. In that case your bootloader must support this and your bootloader must know from which address it must boot these two images. Or something like that.
Suffice to say, I believe we should be able to maintain and update our devices as we choose. For security, features, patches, whatever. I don't suspect they will be releasing regular kernel updates and if I decide to use this board as part of a real project we need to be able to maintain updates. It's a great little board, it'd just make it that much better if we could get some documentation on building our own bootloader/kernel without needing to reverse engineer it.
Well, I got it to work by compiling the appropriate dts with the zImage in the kernel. There was a .dts for me already in the 3.14 kernel tree (exynos4412-tiny4412). It now boots the kernel but I'm working through finding all the drivers for all the pieces on board now. Thanks for all the help Juergen and bluscape.
Ahh! That is great news! Well done! I got busy with other things again. Will see when do I get a chance to work on the NanoPC again. May I ask for your email to share info? Cheers
So far my hurdle is finding the right driver for the onboard eMMC. I have everything in the MMC/SD options enabled and yet the kernel still panics on boot unable to mount the rootfs. I don't want to give a full address on a publicly scrapable board but my gmail is fsalucard. Thanks
Do you support the correct file systems (ext2, ext3, etc.)? Is your bootloader booting from the correct block?
Yes, it just doesn't see the onboard eMMC. If I leave the SD card I flash it from in, it identifies that as mmcbkl0 and tries to mount it there, which obviously doesn't work. If I take that out, it just fails to mount root filesystem and says "available partitions:" with nothing listed.
This whole eMMC/SD business ... maybe the Ordriod U3 forum http://forum.odroid.com/index.php might hold clues as there seems to be quite a bit of similar traffic on that site.
And the hardware is quite similar.
Davef, Thanks for the tip. I rebuilt my dtb in my kernel with the exynos4412_odroidx config instead of the tiny4412, and now my eMMC/SD card is discovered. It mounts the rootfs now.. but kernel panics shortly after lol. Not much in way of useful information either.. So I'll keep working at it.
What is the first error message?
There isn't really an error message. It just panics. [ 5.160000] mmcblk0rpmb: mmc1:0001 M8G1WA partition 3 128 KiB [ 5.165000] ALSA device list: [ 5.165000] No soundcards found. [ 5.170000] mmcblk0: p1 [ 5.175000] mfc-power-domain: Power-off latency exceeded, new value 361833 ns [ 5.180000] mmcblk0boot1: unknown partition table [ 5.185000] mmcblk0boot0: unknown partition table [ 5.195000] EXT4-fs (mmcblk0p1): mounted filesystem with ordered data mode. Opts: (null) [ 5.195000] VFS: Mounted root (ext4 filesystem) readonly on device 179:1. [ 5.205000] devtmpfs: mounted [ 5.210000] Freeing unused kernel memory: 332K (c0931000 - c0984000) [ 5.230000] Unhandled fault: imprecise external abort (0xc06) at 0xb6fed008 [ 5.250000] Kernel panic - not syncing: Attempted to kill init! exitcode=0x00000007 [ 5.250000] [ 5.250000] CPU: 0 PID: 1 Comm: linuxrc Not tainted 3.14.4-FriendlyARM #3 [ 5.250000] [<c001b3f4>] (unwind_backtrace) from [<c0017900>] (show_stack+0x10/0x14) [ 5.250000] [<c0017900>] (show_stack) from [<c066a51c>] (dump_stack+0x90/0xc8) [ 5.250000] [<c066a51c>] (dump_stack) from [<c0669b28>] (panic+0xa4/0x1f0) [ 5.250000] [<c0669b28>] (panic) from [<c0029f10>] (complete_and_exit+0x0/0x1c) [ 5.250000] [<c0029f10>] (complete_and_exit) from [<00000001>] (0x1) [ 5.250000] Rebooting in 5 seconds..
There is an error message: [ 5.230000] Unhandled fault: imprecise external abort (0xc06) at 0xb6fed008 Your kernel tries to start the userland init process and fails. How did you generate your root filesystem?
Juergen, How can you tell it's failing in the init process? The whole problem with imprecise aborts is that they are imprecise... that is, the fault is not detected until after (sometimes well after) the faulting instruction has been processed... The call stack that's shown is just what happens to be upstream of the PC at the time the fault was detected but is not likely to be what caused the fault when it is "imprecise". I thought the only way to zero in on imprecise faults was kernel debugging. If you have other magic beans, please do tell... I am dealing with imprecise faults of my own (but only after the system has been up and running for awhile). Aggravating.
Juergen, I appreciate the info but instead of me trying to explain how I'm building the rootfs can you explain the "proper" way to do it? This same rootfs works fine using the kernel released from the QT distro, so I'm not sure why it would be the rootfs fault that this kernel is panicing. Thanks
> How can you tell it's failing in the init process? I often saw such kind of error message. And always the userland/root filesystem was broken somehow. Sometimes due to a wrong toolchain, sometimes due to missing libraries, sometime due to wrong ABI, wrong math and so on...
Hello! I have a similar task: kernel 3.15 on NanoPC. I have built kernel image + dts information, and now have halt after: "Uncompressing Linux... done, booting the kernel.". Can anyone give me any ideas?
Hi, I have done some work on the nanopc-t1 trying to make an *useable* mfc kernel. Fistly i have noticed that the nanopc kernel is based of odroid 3.8 sources, i tried to hack around a new odroid version, but there's still work to be done, regulators stuff: https://github.com/leojrfs/linux-nanopc-t1 I have a SD & emmc booting device tree file for mainline linux here: https://github.com/leojrfs/nanopct1-dts I wont be on this forums, so, create issues on the respective github repos.