wildcat_paris

Huh?
 
Step 1) ALWAYS immediately check an SD card directly after purchase. It's easy. Just do it.
 
Step 2) ALWAYS do a verify after burning an OS image to flash media. ALWAYS.
 
Again: http://docs.armbian.com/User-Guide_Getting-Started/#how-to-prepare-a-sd-card
 
Checking single files won't help. I had strange symptoms (boot failures not always but often and later instabilities) when burning OS images with an USB SD card reader and bs=10M -- switching to bs=1M helped but I lost so much time that I simply said to myself: C'mon, don't be an idiot any more. Use Etcher instead since everytime you try to save time skipping thea verify you loose so much more time hunting bugs that are simply the result of a broken burning process.
 
BTW: Regarding counterfeit SD cards there is no such thing like a 'reliable supplier' since fakes are sometimes inserted into supply chain pretty early. A re-seller gets 100 cards and 5 to 10 are fake. That's why step 1) above is that important.
 
BTW 2: A verify as it's done by Etcher after burning an OS images also doesn't help when you got a counterfeit card. What most people don't understand is that the filesystem layout above the card's block/page management (the so called Flash Translation Layer FTL) is 100 percent abstracted. The only way to detect a fake or broken card is to completely overwrite it with known data patters and verify them at least once.

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.

If that can help, I found the same error message ( spl: mmc init failed with error: -123 ) in the attached file (log1.txt) in this thread : http://forum.armbian.com/index.php/topic/1945-orange-pi-plus-2e/?p=15020
 
I remove  linux-u-boot-orangepiplus-default package and upgrade. Now I can boot :
 
 
 
Thank you very much
 
Now I have two sdcard so if you want help to test new image, no problem, feel free to ask me

Same problem with a NEW Samsung EVO microSDHC UHS-I (48MB/s) and Armbian_5.20_Orangepiplus_Debian_jessie_3.4.112.img image :
 
U-Boot SPL 2016.09-armbian (Sep 15 2016 - 07:58:09) DRAM: 1024 MiB Trying to boot from MMC1 MMC: no card present spl: mmc init failed with error: -123 SPL: failed to boot from all boot devices ### ERROR ### Please RESET the board ###

the only things left were either a wrong write or a wrong image
dd img to sdcard under linux
dd pipe to sha256sum, wrong
dd img to sdcard under windows, dd pipe it to sha256sum, the same wrong value
 
used win32diskimager, sha256 is correct, sdcard boots, i left it alone for for now to do its work
 
either i don't know how to use dd maybe some of the weird options like notrunc or whatever, or dd is dumb
 
now i'm going to play some obduction to calm down, i am angry at myself because i was almost certain your image was wrong... after all how could you develop for a board you don't even have? But I had more trust in you (because you are people) than i have in computers (because... computers...) and thankfully i insisted on checking as much as i could before i started pointing fingers
 
thank you for your work and if you need anything tested on a cb2just ask, i'm handy with both hw/sw

Unfortunately we don't have Cubieboard 2, so we can't debug booting issue on this board.
 
This is strange. If board boots from NAND while SD is inserted, then it means that SPL signature was not found on the card or SD failed to initialize.
 
So system booted from NAND detects SD card and detects partition table on it (since /dev/mmcblk0p1 is created)?

We need this on a long term but any new idea or paradigm switch needs time, perhaps some encouragement. Persistence 

We will be handing out a few armbain mugs at the Ohio Linux Fest (while supplies last).
 
Come see us at the Linux Podcasters Corner!
 
TJoe(h^);
                                              
 

I can only agree.
 
UUID will be very helpful when testing to boot a new image on SDcard while having a working system on eMMC (where you cannot remove the eMMC flash memory -- I only know hardkernel doing removable eMMC)

thinking of http://forum.armbian.com/index.php/topic/2043-lamobo-r1-520-swconfig-problem-with-last-520-armbian-update/?p=15773
 
We may ask the forum users and create a list of testers for each board (or family of boards)
 
=> we could create a sub forum Armbian/Tech/Dev/Armbian build framework/Testing/
- to call for testers when needed (testers would register a pined thread managed by Igor/Mikhail/Thomas/others)
- to report testing on the forum using a title like [5.20/Lamobo-R1] "Status" (OK/KO/minor issues)
- create bug reports in appropriate forum
 
each registered testers creates its minimum set of test (like testing the switch config of Lamobo-R1) and create a thread as a reference
 
(just an idea)
 
 
 
 

Patch should look like this: add-can-driver.zip
You should unpack it to userpatches/kernel/sun7i-default/ and then compile kernel with KERNEL_CONFIGURE=yes to activate new kernel options
 
Edit:
Don't forget that you also need to enable CAN in FEX file
[can_para] can_used = 1

I have pushed some changes for XU4 with the help of so many internet sources (thanks!)
- uboot 2016.05
- vanilla kernel (4.7.6 as of now)
- single partition (using the LABEL=rootfs for booting)
- SD & eMMC
 
for eMMC, burn the image on both a SD card & eMMC first, boot with SD card to write files on mmcblk0boot0 partition, then
cd /usr/lib/linux-u-boot-next-odroidxu4_5.21-GRO_armhf (probably remove -GRO) -rw-r--r-- 1 root root 15616 oct. 1 01:58 bl1.bin.hardkernel -rw-r--r-- 1 root root 14592 oct. 1 01:58 bl2.bin.hardkernel.1mb_uboot -rw-r--r-- 1 root root 1807 oct. 1 01:58 sd_fusing.sh -rw-r--r-- 1 root root 262144 oct. 1 01:58 tzsw.bin.hardkernel -rw-r--r-- 1 root root 548159 oct. 1 01:58 u-boot-dtb.bin then
sudo bash ./sd_fusing.sh /dev/mmcblk0 eventually, remove the SD card, power-off, boot from eMMC
 
Please, I would need help to check the changes, probably testing with Xenial (as I am using CLI Jessie so far)
 
you can fetch the source here
https://github.com/golfromeo-fr/lib/tree/gro_master
or later in the master branch https://github.com/igorpecovnik/lib/issues/482
 
thanks!
 
some config I am using
 
 
note: zador.blood.stain is making the framework so well, it's getting quite easy to achieve this. So nice!

Hi,
 
I'm Olivier, french engineer, and i have bought an orangepi plus card in april. I use linux (x86) since 1994
 
Sorry for my bad english ...
 
I was happy to find Armbian because linux images provided by xunlong have many security problems (example / and all system directory aren't owned by root  but by orangepi user). 
 
Thank for your work on Armbian.
 
My Orangepi + has been installed with a 5.10 armbian image (Armbian_5.10_Orangepiplus_Debian_jessie_3.4.112) and run perfectly.
 
I wanted upgrade to 5.20 and since the card doesn't boot anymore. I can boot with the native android on NAND memory but I can't boot on SDcard. When I boot on sdcard, only green led is on (not red led) and I don't have any display on my HDMI screen.
 
I can restore my sdcard image back up with v5.10 and boot again, the card is OK for me.
 
I followed the upgrade documentation to pass from v5.10 to v5.20 :
 
apt-get update
apt-get upgrade
apt-get install -f
apt-get upgrade
apt-get autoremove -y
 
and i had an error message during first apt-get upgrade :  /boot/initrd.img-3.4.112-sun8i does not exist. Cannot update.
 
I can mount the sdcard on my linux box (an archlinux) and list directories without problem :
 
on my sdcard image backup (v5.10), in /boot I have :    
 
Any idea ? 
 
here is the all message of upgrade process :
 
 
 

et voilà, I am a true goldfish_paris
 
this one works... better writing to come... LABEL is working so I guess UUID will be working as well.
 
I am so dumb... never forget the initramfs, if not you don't have the modules...
setenv bootargs "console=tty1 console=ttySAC2,115200n8 root=LABEL=root rootfstype=ext4 rootwait rw earlyprintk"; load mmc 0:1 0x40008000 /boot/zImage; load mmc 0:1 0x42000000 /boot/uInitrd; load mmc 0:1 0x44000000 /boot/dtb/exynos5422-odroidxu4.dtb; bootz 0x40008000 0x42000000 0x44000000; so next better writing then PR the changes

Hello!
 
I'm new here. I have an MXQ PRO 4k box with S905 inside. I was successful to put Armbian onto an MMC card and it runs amazingly. Video acceleration, sound, ethernet work out of the box.
I'd like to give it to my daugther (10 years old) to learn programming in Scratch which also runs great.
 
Anyway, I cannot make the internal wifi work which would be essential for her for basic communication as well as do more in python later on.
 
QUESTION: how to know / check what wifi chip is built into this unit? It still has android on its own flash and it uses wifi well. I tried to dig out from its android what wifi chip it has but found nothing except a few wpasupplicant settings.
 
On pc I'd do it with lsusb or lspci but I'm new to ARM and also Armbian.
 
thanks
Robert
- a father with concept -
 

Builds can be reproducible but they might not be exactly since we are attached to external source projects and we are fixing things daily.
 
 
Sources are more or less trusted (mainline kernel and uboot, legacy sources maintained by vendors, some community, some mixed, ...). They are git cloned with https, so nothing gets in between.
 
 
Each developer has it's own environment and our common end result is public on Github. Code is review upon commits so I would say yes. Official build is (so far) always done by me on a dedicated hardware, accessible locally and output is securely transferred to download server which will get ssl when admin of the server gets up and finds time.
 
Armbian project is still a small one no matter of importance. Our core team resources and budget are tiny, on a hobby level, so even some things are possible, we might not be able to afford them. But we take security seriously and possible problems will be fixed ASAP ... just this ASAP will take longer
 
Sometimes is hard to see even most obvious things so I only thank you for bringing ideas up. I certainly don't want that our work becomes involved in something like this

the nice thing with the Armbian tool is "this is all scripted"
 
so you can trace anything you want while you build your own image. So you can check yourself with your security team, if it is accurate for you.
 
Then if something is not right for you, you can fork the project and fix it as you need (making the whole community benefits from your changes if needed)

There was an internal change and git cloning function was replaced. Now you need to specify
KERNELBRANCH="tag:v4.7.3" for tags (and
KERNELBRANCH="branch:master" for branches)

for the patch to be created & applied properly you have to pay attention to the path
 
example:
--- a/arch/arm/boot/dts/sun4i-a10-cubieboard.dts +++ b/arch/arm/boot/dts/sun4i-a10-cubieboard.dts assuming you have 2 folders (a, b ) and you want to create a patch for the file arch/arm/boot/dts/sun4i-a10-cubieboard.dts
 
you have to "cd" on the higher directory then
 
diff a/arch/arm/boot/dts/sun4i-a10-cubieboard.dts b/arch/arm/boot/dts/sun4i-a10-cubieboard.dts > $HOME/my.patch
 
note: usually the patch command is used with the option "-p1" so ignoring folder a & b when patching
 
of course, you can trick the patch and
diff sun4i-a10-cubieboard.dts.old sun4i-a10-cubieboard.dts.new
then replace the header with
--- a/arch/arm/boot/dts/sun4i-a10-cubieboard.dts +++ b/arch/arm/boot/dts/sun4i-a10-cubieboard.dts --
you may need to read some more piece of info
https://duckduckgo.com/?q=creating+a+patch+with+diff
 
http://stackoverflow.com/questions/23390823/creating-patch-file-for-linux-kernel#23390933
http://linux.byexamples.com/archives/163/how-to-create-patch-file-using-patch-and-diff/

Then everybody using Ubuntu on PC is named Noah. You see? I'd think it's an incompatibility in Armbian of some sort but I am not skilled enough to debug systemd based initramfs issues.

Oh well, sudo modprobe overlayfs indeed adds the overlay filesystem to /proc/filesystems. I am so used to automagic loading of modules that I didn't think of this. My fault.
Thank you, goldfish_paris!
 
Though adding "overlayfs" to /etc/modules didn't help the overlayroot package to start working correctly. Something else is wrong.

You can edit default environment or default boot sequence (via patches), but I think we don't understand each other.
 
Main purpose of testing would be "here are pre-release images, please write them to SD card and check if they boot fine". If images don't boot we have to build them and upload them again, issues that don't affect boot process can be fixed after the release i.e. by upgrading packages.
 
I don't want to argue with your logic (and it seems like we are talking about different things), but "unique" part of UUID is a big advantage for me to consider it as default method for mounting filesystems.

Which none of the boards have, and thus they support only limited number of boot media for SPL and u-boot. And you still have to test u-boot and standard boot script.
 
So if you have system on SD for testing, on eMMC for everyday use and on connected card reader because why not (i.e. forgot to disconnect) rootfs by label won't be the most reliable method for testing.

From what I remember:
Cubieboard 2 Lime2 and Lime2-eMMC Some i.MX6 boards, don't know much about them so can't say more specific Pine64 (512MB) and Pine64+ (2GB) Different revisions of Beelink X2 Roseapple Pi (?)  
On most boards you need SD/eMMC to start u-boot and feed it with initial configuration, with exception for most Allwinner boards that can use FEL mode or SPI flash for this purpose (SPI Flash support needs to be explicitly enabled in u-boot configuration for this to work) For TFTP you also need Ethernet support in u-boot, otherwise you'll have to load kernel, initrd and DTB from storage too Whether using root on NFS can be used for finding regressions in packages or OS configuration, booting whole images from SD card should still be done before the release to properly test u-boot and boot script, especially if we start moving towards UUID based filesystem mounts

@goldfish_paris I posted some performance results on GitHub. It looks like that since kernel 4.8 the XU4 is very stable and USB3 works fine (but let's say not with all SATA-USB3 adapters)
 
I got new u-boot from here as well:
 
upgrade firmware  ================ https://github.com/c0d3z3r0/xu4-update An easier way to update the firmware of your Odroid-XU4. root@bananapi:/# lsblk NAME        MAJ:MIN RM  SIZE RO TYPE MOUNTPOINT sda           8:0    1  7.4G  0 disk +-sda1        8:1    1  100M  0 part /media/boot +-sda2        8:2    1  7.3G  0 part /media/root mmcblk0     179:0    0  7.4G  0 disk +-mmcblk0p1 179:1    0  7.3G  0 part / root@bananapi:/# vi /usr/bin/xu4-update root@bananapi:/# ROOT_PATH=/media/root BOOT_PATH=/media/boot SD_DEV=/dev/sda xu4-update  *** Odroid-XU4 firmware updater by c0d3z3r0  *** based on rpi-update by Hexxeh, enhanced by AndrewS and Dom  *** Performing self-update  *** Relaunching after update  *** Odroid-XU4 firmware updater by c0d3z3r0  *** based on rpi-update by Hexxeh, enhanced by AndrewS and Dom  *** We're running for the first time  *** Backing up files (this will take a few minutes)  *** Backing up firmware  *** Backing up modules 4.6.3-sunxi  *** Downloading specific firmware revision (this will take a few minutes)   % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current                                  Dload  Upload   Total   Spent    Left  Speed 100   168    0   168    0     0    118      0 --:--:--  0:00:01 --:--:--   118 100 25.8M    0 25.8M    0     0  1515k      0 --:--:--  0:00:17 --:--:-- 2154k  *** Updating firmware  *** Updating kernel modules  *** depmod 4.7.2+  *** Writing new bootloader to sd card 30+0 records in 30+0 records out 15360 bytes (15 kB, 15 KiB) copied, 0.00736964 s, 2.1 MB/s 28+1 records in 28+1 records out 14592 bytes (15 kB, 14 KiB) copied, 0.0105246 s, 1.4 MB/s 1070+1 records in 1070+1 records out 548191 bytes (548 kB, 535 KiB) copied, 0.207144 s, 2.6 MB/s 512+0 records in 512+0 records out 262144 bytes (262 kB, 256 KiB) copied, 0.272539 s, 962 kB/s  *** Running ldconfig  *** Storing current firmware revision  *** Deleting downloaded files  *** Syncing changes to disk  *** If no errors appeared, your firmware was successfully updated to 8bdbdebd6f60a1212e3d7b78835e9775f89bbc6d The foillowing example shows how to upgrade offline. I took my banana pi to upgrade the kernel offline, which it means that you insert your uSD-Card in the USB-Adapter on the Banana Pi and execute the upon described procedure. With this easy step we achieved a new kernel but the more important, the new U-Boot 2016.05-dirty
 
Take care because after that we have the boot.scr boot script