So iwe been trying to solve this issue by experimenting and iwe hit a wall where i do not know what to do so i guess i'm just hoping someone would spot what i'm doing wrong.
So i bought an "Orange Pi PC" from ebay and i'm trying to set it up without much sucess.
I downloaded the "Armbian_5.14_Orangepi2_Ubuntu_xenial_3.4.112.raw" image from the armbian webpage. ( I also did my Cubieboard wich worked fine with the same steps. )

The commandline i used to write the image to an sdcard is this:
sudo dd if=./Armbian_5.14_Orangepi2_Ubuntu_xenial_3.4.112.raw of=/dev/sdc bs=1M oflag=direct
sudo sync

And then i unplug the sd card and put it into my OrangePi and when it boots the green led keeps flashing with simular intervalls.
It was not until i got frustrated enuff to hook the debug TTL/ftdi up to see what the hell it was doing i spotted this:
 

U-Boot SPL 2016.05-armbian (Jun 20 2016 - 12:52:49)
DRAM: 1024 MiB
Could not determine boot source

resetting ...

And it just kept looping with that text and each time it was resetting the green led shut off for a short period of time.

Anyhow i did try the ubuntu and debian versions from the orangepi project and it did boot but they got a FAT32 partition called "BOOT" but the network card fails on that one but that "BOOT" partition is the main diffrance i spot between armbian and the other images i found so i'm wondering why the armbian one does not use it... i might be heading into overthinking the whole issue abit too much state wich is why i desided to write a forum post here instead.
 

More info on what iwe done and tested:
I did test this sdcard in my raspberry pi 3 and downloaded a ubuntu iso and sha256 to see if the card sd card was a real 8gb card ( just to rule it out ).
I did test with another sd-card, same issue.

Output from fdisk:

   Device Boot      Start         End      Blocks   Id  System
/dev/sdc1            2048     2988031     1492992   83  Linux

Output from fsck:
 

$ sudo fsck.ext4 /dev/sdc1 -f
e2fsck 1.42.9 (4-Feb-2014)
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
/dev/sdc1: 49628/93312 files (0.1% non-contiguous), 263806/373248 blocks

Not sure if it's relevant but the text on the PCB itself says "Orange PI PC v1.7" ( Just trying to give asmuch info as i can )

@tbbw

 

I am wondering why you are using Armbian_5.14_Orangepi2_Ubuntu_xenial_3.4.112.raw

 

when http://www.armbian.com/orange-pi-pc/

the image is Armbian_5.14_Orangepipc_Debian_jessie_3.4.112

http://mirror.igorpecovnik.com/Armbian_5.14_Orangepipc_Debian_jessie_3.4.112.7z

I have tryed both Orange-pi-2 and Orange-Pi-PC image.
I'll download that link you posted and dd it to the sdcard.
I'll post an update once iwe done this.

Get a simular error thru the serial console with the image you linked to:
 

U-Boot SPL 2016.05-armbian (Jun 05 2016 - 09:45:23)
DRAM: 1024 MiB
Card did not respond to voltage select!
Could not determine boot source

resetting ...

There is no "BOOT" partition in this image eather just an ext4 partition wich is the same as my previus trys.
I do see ppl mentioning a FAT32 partition in other topics here and there on this forum so i'm not sure why i do not have one.



 

$ wget http://mirror.igorpecovnik.com/Armbian_5.14_Orangepipc_Debian_jessie_3.4.112.7z
--2016-06-27 05:41:21--  http://mirror.igorpecovnik.com/Armbian_5.14_Orangepipc_Debian_jessie_3.4.112.7z
Resolving mirror.igorpecovnik.com (mirror.igorpecovnik.com)... 185.94.112.69
Connecting to mirror.igorpecovnik.com (mirror.igorpecovnik.com)|185.94.112.69|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 210033454 (200M) [application/x-7z-compressed]
Saving to: ‘Armbian_5.14_Orangepipc_Debian_jessie_3.4.112.7z’

100%[===================================================================================================================================================================================================>] 210,033,454 2.66MB/s   in 76s

2016-06-27 05:42:37 (2.64 MB/s) - ‘Armbian_5.14_Orangepipc_Debian_jessie_3.4.112.7z’ saved [210033454/210033454]

$ 7za x Armbian_5.14_Orangepipc_Debian_jessie_3.4.112.7z

7-Zip (A) [64] 9.20  Copyright (c) 1999-2010 Igor Pavlov  2010-11-18
p7zip Version 9.20 (locale=en_US.UTF-8,Utf16=on,HugeFiles=on,4 CPUs)

Processing archive: Armbian_5.14_Orangepipc_Debian_jessie_3.4.112.7z

file armbian.txt
already exists. Overwrite with
armbian.txt?
(Y)es / (N)o / (A)lways / (S)kip all / A(u)to rename all / (Q)uit? y
Extracting  armbian.txt
Extracting  Armbian_5.14_Orangepipc_Debian_jessie_3.4.112.raw.asc
Extracting  Armbian_5.14_Orangepipc_Debian_jessie_3.4.112.raw

Everything is Ok

Files: 3
Size:       1427131270
Compressed: 210033454
$ sudo dd if=./Armbian_5.14_Orangepipc_Debian_jessie_3.4.112.raw of=/dev/sdc bs=1M oflag=direct
1361+0 records in
1361+0 records out
1427111936 bytes (1.4 GB) copied, 277.947 s, 5.1 MB/s
$ sudo sync

Could anyone that has a booting OPi2 or OpiPC check if they got a boot partition on ther sd card or am i chasing unicorns thinking about this?

Hi

There is just a single partition:

/dev/mmcblk0p1 on / type ext4 (rw,noatime,nodiratime,errors=remount-ro,commit=600)
Check your power supply

Hi

There is just a single partition:

/dev/mmcblk0p1 on / type ext4 (rw,noatime,nodiratime,errors=remount-ro,commit=600)

Check your power supply

Ok so the whole boot partition idea/brain worm can go to rest.

I am feeding it from a regular pc powersupply so it should be getting more then it needs.

The cubieboard1 runs fine with the same supply with a laptop sata drive attached to it so does the Raspberry Pi 3.

 

I get the OrangePi's linux images to boot on an sdcard but it's an entire diffrent can of worms why i dont want to use those images instead of armbian

So i must be screwing something up.

Did you went through these steps already? https://github.com/igorpecovnik/lib/wiki/Getting-started#how-to-prepare-sd-card

 

(I'm talking about the 'Boot problems? How to ensure your SD card is ok' steps and what sort of cards we recommend)

 

BTW: Since you have a serial console attached and get messages back from u-boot ('Card did not respond to voltage select!' or 'Could not determine boot source') this means that u-boot starts but then has trouble to figure out how to proceed. Never seen that myself but my 'workaround' would be to buy a new Samsung EVO and try it again with this (never trying out old and obviously ultra slow cards like you do -- 5 MB/s writing speed sounds to me like 'totally insufficient SD card used')

I just whent with a kingston sd card since speed was not my main consern since the whole plan was to use the cubieboard with a harddrive running armbian and NFS it over to the RPi3 and OPiPC for some of the heavy stuff.

Running F3 now, will post result soon.

Edit:
Getting errors at the end of the sd card ( at 99.3% in F3. ).
So i'll guess a trip to my local computer store for a warranty issue and get it replaced.

dmesg output:

[4509220.766159] EXT4-fs warning (device sdc1): ext4_end_bio:317: I/O error -5 writing to inode 18 (offset 983425024 size 2572288 starting block 230500)
[4509220.766233] EXT4-fs warning (device sdc1): ext4_end_bio:317: I/O error -5 writing to inode 18 (offset 983425024 size 2572288 starting block 230530)
[4509220.766278] EXT4-fs warning (device sdc1): ext4_end_bio:317: I/O error -5 writing to inode 18 (offset 983425024 size 2572288 starting block 230560)
[4509220.766322] EXT4-fs warning (device sdc1): ext4_end_bio:317: I/O error -5 writing to inode 18 (offset 983425024 size 2572288 starting block 230590)
[4509220.766363] EXT4-fs warning (device sdc1): ext4_end_bio:317: I/O error -5 writing to inode 18 (offset 983425024 size 2572288 starting block 230620)
[4509220.766404] EXT4-fs warning (device sdc1): ext4_end_bio:317: I/O error -5 writing to inode 18 (offset 983425024 size 2572288 starting block 230650)
[4509220.766446] EXT4-fs warning (device sdc1): ext4_end_bio:317: I/O error -5 writing to inode 18 (offset 983425024 size 2572288 starting block 230680)
[4509220.766488] EXT4-fs warning (device sdc1): ext4_end_bio:317: I/O error -5 writing to inode 18 (offset 983425024 size 2572288 starting block 230710)
[4509220.766530] EXT4-fs warning (device sdc1): ext4_end_bio:317: I/O error -5 writing to inode 18 (offset 983425024 size 2572288 starting block 230740)

So i'll guess a trip to my local computer store for a warranty issue and get it replaced.

 

Hmm... since all Kingstons tested so far are horribly slow (random IO with smaller block sizes) I won't use one for anything else than the bootloader when rootfs is somewhere else (USB or NFS for example -- but NFS with just Fast Ethernet isn't that much fun either I would suppose).

 

So it's just a hardware issue as usual and the u-boot version Armbian is relying on (mainline u-boot from this year) seems to be more picky about SD cards than the one used on other 'common' OS images for Oranges (u-boot 2011.09 from Allwinner -- I think we and jernej's OpenELEC are currently the only ones relying on mainline u-boot, everyone else uses the outdated version). BTW: It seems not possible any longer to assign the [sOLVED] prefix to a topic title? @Igor: Did you change anything?

Yeah i guess you can add the [sOLVED] to it.
I'll see if i cant get em to let me pay an extra dollar to upgrade to a "SanDisk microSDHC Mobile Ultra 8GB (Class 10) 48MB/s" card instead and try with that.

Well NFS works realy well for what i intend to use it for

upgrade to a "SanDisk microSDHC Mobile Ultra 8GB (Class 10) 48MB/s" card instead and try with that.

 

Also slow as hell. SanDisk gets interesting when choosing Extreme Pro or Plus. Best buy at the moment are Samsung EVO with 32 or 64 GB on boards like Oranges where sequential transfer speeds are limited by the host's SDIO implementation. Since they're both cheap and show excellent random IO performance while being fast enough when it's about sequential transfer speeds: http://forum.armbian.com/index.php/topic/954-sd-card-performance/

Hmm... 32gb is abit wastefull.
I do see a 16gb samsung evo's but it's three times the price of the sandish one.
All i will be doing is just boot up the os and then do most of my stuff in the folder i mount my nfs share in and that will go to the cubieboard's sata drive.
The whole idea was so i could just copy the sd card and add more OPi's as i need em and use ther mac addresses to make a unique folder on the NFS share to have ther personal storage in.
I was exploring NFS boot but it's way too much work and i can fit the entire OS on just a 8gb sd card and have plenty of room to spare.
I am abit puzzled why the cubieboard and the RPI3 boots with the same type of sd card as i failed to use in the OPi PC.

I am abit puzzled why the cubieboard and the RPI3 boots with the same type of sd card as i failed to use in the OPi PC.

 

Well, the good piece of news, your board is working...

 

just an idea... the CBi and RPi3 have less "powerful/demanding" SDcard reader so the same card doesn't work on OPi.

I remember RasberryPi foundation has a page with compatible/incompatible SDcards so it depends on the SoC/reader hardware as well.

U-Boot SPL 2016.05-armbian (Jun 20 2016 - 12:52:49)
DRAM: 1024 MiB
Could not determine boot source

resetting ...

 

I am abit puzzled why the cubieboard and the RPI3 boots with the same type of sd card as i failed to use in the OPi PC.

There are many possibilities. Error that you got means that BROM (bootloader in SoC) failed to start SPL in a proper way. It may be caused by a hardware issue (with your board and/or SD card), it may be an incompatibility between BROM and this card (happens sometimes) or broken OS image (corrupted during build, download or write to card process)

 

I was exploring NFS boot but it's way too much work and i can fit the entire OS on just a 8gb sd card and have plenty of room to spare.

NFS boot is not that hard to set up.

Well, the good piece of news, your board is working...

 

just an idea... the CBi and RPi3 have less "powerful/demanding" SDcard reader so the same card doesn't work on OPi.

I remember RasberryPi foundation has a page with compatible/incompatible SDcards so it depends on the SoC/reader hardware as well.

Well it does boot up with the OrangePI's linux builds exept those had the fat32 partition with an script.bin and uImage there wich was why i was stuck for two days investigating if i could recreate it somehow... i generaly wasted a ton of time fiddeling with something that was not broken in the sence i imagined.

And the network card was spamming IRQ errors in dmesg and since i was not aiming to use that build since i wanted armbian i did not bother to investigate or try to get it running properly.

 

 

There are many possibilities. Error that you got means that BROM (bootloader in SoC) failed to start SPL in a proper way. It may be caused by a hardware issue (with your board and/or SD card), it may be an incompatibility between BROM and this card (happens sometimes) or broken OS image (corrupted during build, download or write to card process)

 

NFS boot is not that hard to set up.

I know, but you still need to be able to boot something to run a nsf root no boot no fun

 

Eather way i did get some peace of mind knowing the commands i used and the images i downloaded should work so i guess it wont hurt to try with an oversized overpriced sd card just to rule that out coz i was at the point where i tryed everything i could think of by myself and i was getting realy frustrated.

It is kinda silly that these kingston SDC4/8GB ( to record wich card it was incase someone stumbles on this thread with simular issue ) does not work in the OPi PC.. one would expect them to work exept be slower then the more expensive ones.

 

SDC4/8GB

I know, but you still need to be able to boot something to run a nsf root no boot no fun

 

In fact thanks to zador Armbian's build system enables a whole NFS/FEL boot scenario just by choosing the right option (so you can study what the script does and make you Cubie to an NFS server). Also using our build system choosing 'nfs' as rootfs type is now possible so the whole process is pretty easy.

 

If your Cubie is a Truck (2 GB DRAM) you could even use mainline kernel, btrfs and then snapshots for every NFS shared rootfs for different SBC and you will only need very limited storage even for a large amount of boards.

 

Regarding your Kingston card 'SDC4/8GB' is not sufficient to differentiate between 'good' and 'bad' Kingstons. Kingston buys on the spot markets what's cheap at that moment and then combines controllers and NAND dies from different sources to storage media that might fulfill the sequential speed promises (the 'speed class') but normally totally sucks when it's about random IO. This also means two Kingston 'SDC4/8GB' might be made of absolutely different ingredients and one shows problems, the other not. 

 

The most important part of the product spec is the 4 in 'SDC4' since this means 'speed class 4' or in other words: Way too slow anyway. You put class 4 cards in old digicams or in the trash but never in an SBC Armbian should run on later. Since it's just wrong. SDC4 from Kingston is no name quality at a premium price. And at least here in Germany if I compare the prices then I simply would've to be mad to buy such lousy cards. It's €8,19 for a 32GB Samsung EVO vs. €7,96 for such a SDC4 with the same capacity but magnitudes slower. That's €0,23 less for the crap card compared to a good one that's way faster.

Well between a Class10 card from Sandisk and the kingston one there as literaly just 1dollar diffrance.
So almost 10 times the speed for a dollar.
I have not yet gotten the card... they still need to approve my warranty claim on the one F3 failed at but i guess i could buy one Sandisk and one Samsung EVO so i cover all bases since i rater just use the Sandisk one if i could but i dont want to be left without been able to use my OPi incase it does not work.
I got another SDC4/8GB that passed F3 (yeah i bot a bunch of em coz i got em on a discount) but it does not want to boot in the OPi so i guess F3 giving a pass does not garantee it will work it just means nothing funky like an out of bound partition or corruption hapend.

Well between a Class10 card from Sandisk and the kingston one there as literaly just 1dollar diffrance.

So almost 10 times the speed for a dollar.

 

Nope. 'Class 10' is worthless, it's all about random IO and SanDisks that are neither Extreme Pro or Plus suck here as well (guys, forget about this absurd 'speed class' -- you use a single board computer and not a digital camera or recorder!).

 

Unfortunately I have no idea where to link to since Armbian documentation moves around faster than I can cope with.

Can anybody explain such issue:

2Gb card written by dd (or win32diskmage) last Jessie or Xenial server. It boots great.

4Gb card written the same way - boot fails.

I make the full image of 2Gb card by win32diskmage, then write this image to 4Gb card - armbian boots great.

 

Cannot understand it and cannot try Jessie desktop.

Cannot understand it and cannot try Jessie desktop.

 

That's great. It's a feature and not a bug and you should be thankful. 2 or 4 GB SD cards in 2016 are horrible crap since random IO will be way too slow. Please do yourself a favour, put this card in the drawer or throw it away, read through this thread and buy a new one: http://forum.armbian.com/index.php/topic/954-sd-card-performance/

 

Android or a desktop Linux really depend on fast random writes. SD cards with 2 or 4 GB are old and will show a horrible performance leading to a horrible user experience. Speed class does not matter at all, it's random IO and this will suck for sure. Don't do this and be happy that whatever reason prevents you from booting with this card. Really!

It doesn't matter what capacity u use. Also cannot boot from Sandisk UHS-I 16Gb, Transend 16Gb 10class. The same problem

Back to Raspberry Pi old times, you will find lists of working/not working SD cards. I bought a number of cards, I dont posses 2 identical ones. I never had one that could not work (the performance is another question). But I also had a number of fails when flashing cards, get corrupted cards (and not being sure if it had been incorrectly dismounted or had bad contacts).

 

So I think you need to test the copy of the image by mounting the filesystem(s) before trying to boot. You will spare a lot of time and improve overall feedback on any cards/os. "It does not boot" is not very helpful with no serial console capture anyway, because we have to guess if it is a PSU, SD card, hardware, install, or software problem and never have a trustful feedback of the problem resolution. (I am not an Armbian team member, and my opinion here is the one of a basic user who cannot make his mind about hardware/software quality).

 

And then, you have to take tkaiser tests into account : if you want to use the SD card for more than just boot or test, buy a good one ! If you want to do some serious project with your card, use eMMC, usb drives or SATA drives on A20 (or hopefully some successor with true SATA controller integration). Personally, I have lost to many time because of bad contacts on SD cards and damaged filesystems, and I cannot sue truck drivers that run in my street ...