Which device is most compatible with raspberry pi?

[crossmax]

Hi!

I'm testing some orange pi device for use it on my projects as a substitute for raspberrypi. I need a device with OS installed on emmc. I have not had good experiences with microsd on raspberrypi due to data corruption. I thought that orangepi device with emmc flash was a good option. However I'm realizing that it is not as compatible as I thought. Make the spi display and spi smart reader work I think that's crazy.

 

For this reason I ask you the following: Whitch device is most compatible with raspberry pi at gpios level? If had emmc or something more robust then microsd it would be better.

 

thanks in advence

 

 

 

[Tido]

see this posting

 - undervoltage can also lead to corrupt SDcard - do proper investigation first on Power issue on your Pi

[tkaiser]

2 hours ago, crossmax said:

I have not had good experiences with microsd on raspberrypi due to data corruption

 

On 1st generation Raspberry Pis (A and B -- the later models fixed that) under-voltage can directly cause data corruption. And then you can always get counterfeit SD cards. If you keep those two issues in mind (and fix under-voltage which is possible even with Raspberries and their shitty Micro USB DC-IN connector by using appropriate cables and test for counterfeit/fake SD cards) you can run Raspberries and every other SBC from SD cards just fine. Please read through whole thread over there: http://tech.scargill.net/a-question-of-lifespan/#comment-33659

[crossmax]

Thanks for both comments. I've to read too much but this articles are so interesting. Some options that are discussed in the articles I've used time ago and I'm getting less microsd errors. And, if I've thinking for a while, where had more microsd errors was on projects with raspberry pi B. Some broken microsd with A+, but many less, 2 or 3 cards to throw away.

 

There is one thing that troubles me, and that I have not yet read anywhere. Many times I corrupt the cards, but are recoverable with run fsck inserting the card into a pc. It rarely happens that the card is unrecoverable runs fsck.

Why this difference in card corruption?

 

Thanks for all great info

[tkaiser]

15 minutes ago, crossmax said:

Why this difference in card corruption?

Well, 'logical' errors above FTL (flash translation layer, that's the 'controller' inside SD cards) vs. those below. Every freeze/crash or reboot loop might add to filesystem corruption that might be cured by fsck (or mkfs) but if things go wrong at lower layers ('SD card itself') then filesystem corruption is not the culprit but only a symptom. Usually SD cards should become read-only when they're worn out but since we're dealing with that much counterfeit cards combining crappy flash dies with a fake controller everything can happen.

 

BTW: I personally experienced SD card corruption only with Raspberry Pis but no other SBC (I even tried hard last year to trigger this but to no avail). Maybe there's some room for improvements in Raspbian with regard to SD card longevity (in Armbian we use a rather large commit interval and log2ram to reduce writes to SD card)

[zador.blood.stained]

AFAIK Raspbian by default doesn't use initrd (and with the RPi limited bootloaders it's not that easy to use it), so filesystem errors on the rootfs simply can't be fixed on-the-fly during boot.

 

disclaimer: I didn't check the situation with modern Raspbian and RPi firmware, but I still believe initrd is not used by default

[crossmax]

2 hours ago, tkaiser said:

BTW: I personally experienced SD card corruption only with Raspberry Pis but no other SBC (I even tried hard last year to trigger this but to no avail). Maybe there's some room for improvements in Raspbian with regard to SD card longevity (in Armbian we use a rather large commit interval and log2ram to reduce writes to SD card)

Thansk for the master class

So, what other SBC did you used without corruption errors? I would like to test other options, as I have done with orange pi, but if the gpio pins are not compatible with raspberry the advantages against this have to be important so that it is worth making software changes.

 

2 hours ago, zador.blood.stained said:

AFAIK Raspbian by default doesn't use initrd (and with the RPi limited bootloaders it's not that easy to use it), so filesystem errors on the rootfs simply can't be fixed on-the-fly during boot.

 

disclaimer: I didn't check the situation with modern Raspbian and RPi firmware, but I still believe initrd is not used by default

 

I will try to launch an initramfs. If I can check the rootfs and fix it, I will considerably reduce the time out of service of the device. Thanks for the tip.

[tkaiser]

24 minutes ago, crossmax said:

what other SBC did you used without corruption errors?

• A10-OLinuXino-Lime (Allwinner A10)
• A20-OLinuXino-Lime2 (Allwinner A20)
• Banana Pi (Allwinner A20)
• Banana Pi M2+ (Allwinner H3)
• Banana Pi M3 (Allwinner A83T)
• Banana Pro (Allwinner A20)
• Beelink Mini MX (Amlogic S905)
• Beelink X2 (Allwinner H3)
• Clearfog Pro (Marvell Armada 385)
• Cubietruck (Allwinner A20)
• Lamobo R1 (Allwinner A20)
• NanoPi M1 (Allwinner H3)
• NanoPi NEO (Allwinner H3)
• NanoPi NEO Air (Allwinner H3)
• ODROID-C1+ (Amlogic S805)
• ODROIC-C2 (Amlogic S905)
• ODROID-XU4 (Samsung Exynos 5422)
• Orange Pi Lite (Allwinner H3)
• Orange Pi One (Allwinner H3)
• Orange Pi PC (Allwinner H3)
• Orange Pi PC Plus (Allwinner H3)
• Orange Pi Plus 2E (Allwinner H3)
• Orange Pi Win (Allwinner A64)
• Orange Pi Zero (Allwinner H2+)
• Orange Pi Zero Plus (Allwinner H3)
• Orange Pi Zero Plus (Allwinner H5)
• pcDuino3 Nano (Allwinner A20)
• Pine64+ (Allwinner A64)
• Pinebook (Allwinner A64)
• Roseapple Pi (Actions Semi S500)
• Wandboard Quad (NXP i.MX6)

(useless list since as Zador and me already explained it's more related to software/settings: high commit interval, reducing permanent writes, ability to do a fsck at boot)

[crossmax]

24 minutes ago, tkaiser said:

• A10-OLinuXino-Lime (Allwinner A10)
• A20-OLinuXino-Lime2 (Allwinner A20)
• .....

(useless list since as Zador and me already explained it's more related to software/settings: high commit interval, reducing permanent writes, ability to do a fsck at boot)

A long list of device!! No doubt you know many SBC 

In production scenarios I included improvements like locating logs in ram (/var/log), logrotate with compression every night and reduce permanent writes setting up in fstab (e.g. root partition noatime,nodiratime,data=writeback,discard,errors=remount-ro     0       0). I don't remember if I adding some little thing, but test a lot of them.

Now, thanks to you I have realized that I have to eliminate a third partition created for me to save some logs when I move it from ram to sd card. I thought it was a good solution to reduce the probability of corrupting the root partition.

Also, I just put to try to make an initramfs work, do I have to keep anything in mind? If run initramfs at boot, I'll can to run fcsk over rootfs if is corrupt, right? And, after that, run the "normal" kernel.

 

I greatly appreciate the help