nz1

Sorry, I was actually referring to the gc2035 camera in message #2. My mistake.

I went on a wild goose chase trying to get this camera to work with my orangepi pc, until I rediscovered this link. http://www.cnx-software.com/2015/09/26/how-to-use-orange-pi-camera-in-linux-with-motion/ I think Armban is already mostly setup to handle this camera, so for me no editing fex files or installing modules was needed.

I think etcher catches errors writing to the card while dd(on osx) will continue without reporting anything. Thats been my experience with two sdcards. Does anyone else notice that the etcher progress bar will make huge forward jumps and then seem to pause for a while? dd piped via pv just seems to write at a steady pace. My current guess is that etcher is communicating with the sdcard using some sort of flash api while dd possibly treats flash as just another cdrom that does not return write errors. I have skim read through some etcher programmer comments and they say something like they are using new code and not using dd code. They also say that dd has bugs.

If someone has an emmc sbc then i think it would be faster to install directly onto the emmc chip from a pc, rather than doing it twice, once onto the sdcard and then onto the emmc chip. I think the total bill of materials will also be less for the emmc sbc as you don't need to buy an expensive(including postage) sdcard to store the os. My understanding is the emmc sbc will probably be faster than any sdcard as emmc chips have better random io and they are designed to work with computers, unlike an sdcard. If the the board does not have a fel button then using an inexpensive sdcard to store the fel boot logic seems ok. Etcher.io will verify the write so that should be enough. One could get by with just one fel boot sdcard if all your sbc cards had emmc chips. It would perform a role similar to a boot cdrom. Some of my thoughts...

How often would it occur that the usb keyboard wouldn't be recognised? What about adding this to a pc and then connecting the sbc to the pc with a usb cable and then using fel boot fallover. Then the usb keyboard problem would go away and the user could select the target board from a list? My 2cents. Your implementation/prototype looks impressive.

My latest card that I ordered comes from the recommended list. It hasn't arrived yet so I haven't used it yet. I got it from Aliexpress because the aliexpress postage is free and I didn't bother with Amazon as I assumed that the postage was going to add to the cost and I didn't want to pay 1/2 to 2/3rds the cost of the actual computer just to buy the sdcard. The emmc option is only $5 extra and I know its compatible and fast, so I'm thinking, why even bother with sdcards if you don't have to. Some of the slowness is probably because the chipset controllers use different logic and are slightly incompatible so when they negotiate speeds they have to use lower speeds. I decided to use a usb hub because I thought it would slow the write down and give the sdcard controller more time to do housekeeping behind the scenes. I think thats why both cards are now working, because the card controller had more time to shuffle bits around while dealing with the fire hose of data being sent to it from the pc. Well thats my theory/guess. Is good that the crc32 values are spot on.

Yesterday I got a new orangepipc+ to replace my orangepipc. I reused my working sdcard from the orangepipc and used etcher.io to write the new orangepipc+ os. However etcher gave errors when writing to this card, even though it had previously been working. I tried again, this time with the sdcard writer attached to a cheap usb hub. The writing process was much slower, at 1MB/s, however this time etcher finished successfully. I used this card to boot the orangepipc+ and used the sata nand script to write the os to the emmc card, without any problems. I also as an experiment tried to write the same img to my broken sdcard using the attached usb hub, and this also worked, and etcher gave the same crc32 values with both sdcards. My thoughts a) Use etcher Sdcards are very unreliable, however they can sometimes fix themselves, just like old HDD drives could sometimes decide to come back to life. c) dd on OSX does not always return errors when writing to sdcards. d) Use emmc single board computers when possible. e) Eagerly wait for an install/boot process that does not rely on sdcards, perhaps using fel and usb cables. Or possibly Orange will release boards with small nand chips so that a small boot linux can be used which enables ftp/http installs.

What did you use to write to the sdcard? dd? I used dd on OSX and with no errors however my orangepipc wouldn't boot. I tried etcher and it would consistently fail during the writing process(ie even before the verification process). I ended up using another sdcard with etcher and it worked fine and booted properly. Note that my failed sdcard used to work in my orangepipc but somehow it failed somewhere. Maybe my fingers touched the contacts and fried it.. who knows.