TheLinuxBug

Okay, FINALLY I have had time to test this... @tkaiser @Andrius @lanefu The issues are as follows: 1. You are lacking the dtb file in /boot (armada-3720-community.dtb) 2. Once the kernel boots it disables UART which is a huge pain 3. Requires manual changes to uboot config at startup (you need serial connection at boot time) To get it to boot: 1. Copied the armada-3720-community.dtb into /boot on the SDcard 2. stopped uboot during start up and entered the following: Marvell>> setenv image_name boot/Image Marvell>> setenv fdt_name boot/armada-3720-community.dtb Marvell>> setenv bootmmc 'mmc dev 0; ext4load mmc 0:1 $kernel_addr $image_name;ext4load mmc 0:1 $fdt_addr $fdt_name;setenv bootargs $console root=/dev/mmcblk0p1 rw rootwait; booti $kernel_addr - $fdt_addr' Marvell>> save Saving Environment to SPI Flash... SF: Detected W25Q32DW with page size 256 Bytes, erase size 4 KiB, total 4 MiB Erasing SPI flash...Writing to SPI flash...done Marvell>> run bootmmc While the UART serial console no longer works, the board is online: Sorry for such a long delay! I will see if I can let this run for a bit and do some performance testing to see the difference between the Armbian kernel and the one I compiled my self. Have a great weekend all! Shameless plug: If you get bored and have Allwinner H3 device, check out H3droid - an Android image developed specifically to work on Allwinner H3 devices! Cheers!

Must have been for you I guess. Have you tried mounting the image as a loop device and changing the kernel to one you compiled? Globalscale includes all the directions needed to build your own kernel on their page.. here you should be able to compile your own kernel, replace it on the .img and burn it again. Then it should boot for you, it seems the kernel currently included on the image isn't for the board or has some issue loading, replacing it should allow you to boot and get into the OS (I am guessing here, I will have to test this my self tonight). In case your not sure you should be able to fdisk -l omv.img find the partition table and calculate the offset by 512*start of partition=offset then losetup -o <offset> /dev/loop0 <file> Once a loop device is created you can then mount /dev/loop0 and once mounted you should be able to change the Image under /boot. Hopefully I will get an opportunity to do this tonight if @tkaiser has his server back online. Cheers!

I honestly have not a clue what you are talking about. I have had no issues getting my ESPRESSOBin up and working, and I am using the u-boot on the built-on SPI NOR on the ESPRESSOBin, not booting u-boot from SDcard (although... you can...). I have a feeling this reply wasn't meant for me cause nothing you provided was useful to me at all. In fact I was offering to test things because others had not had success and mentioned I have already compiled my own kernel and will test with it if the one available with OMV doesn't work. Anyhow... maybe you can remember who that was for and actually tag them instead... Cheers!

Hopefully I can get a chance to test it before then, works been ridiculously crazy and been also working on the H3Droid project so just haven't had time yet. I do fully intend to test though and if needed I will switch out the kernel also for the one I compiled and see if this allows it to run. Just don't go deleting it before I get time to download it ;p Cheers!

Okay, so I got the m.2 SSD working in an m.2 to SATA adapter through the on-board SATA. I have the ESPRESSOBin booting from the SSD at this time. A few thoughts: - For a novice user of u-boot it was necessary to learn how to manipulate scsi devices in u-boot, once I figured this out things were pretty smooth. - For some reason the ASM1061 scsi devices and USB scsi devices are instantiated before the on-board SATA controller, this can make boot time confusing as block devices will be defined in this order and if you boot with a USB disk attached and you don't know about it ahead of time it will effect where your rootfs is located as USB drives will get block device names first. - For me I decided to just remove USB devices at boot and used /dev/sdb1 as my rootfs volume, but if I were to forget and reboot with the USB plugged in the kernel will panic on boot because it can't find rootfs where it is expecting it. I ended up with the following to boot: setenv bootcmd 'scsi scan; scsi dev 0; ext4load scsi 0:1 $kernel_addr $image_name;ext4load scsi 0:1 $fdt_addr $fdt_name;setenv bootargs $console root=/dev/sdb1 rw rootwait; booti $kernel_addr - $fdt_addr' save run bootcmd @tkaiser as I now have it booting off SSD and working as needed I will see if I can burn OMV to my SDcard and test booting it here. Worst case, supposedly per Kickstarter Globalscale has shipped all its 1GB boards out, which should mean my second boards is on its way, so when it arrives, OMV will be my first test with it. Thanks again for all your help and I will follow-up once I have been able to test OMV on the ESPRESSOBin. Cheers!

Yeah I realize now I should have just purchased an 32GB SATA SSD instead of goofing around with m.2 and converters and such, however, at this point I figured it cheaper to cut my losses by buying the m.2 to sata adapter than still buying another drive. Hopefully this adapter arrives and everything works (and I don't find my issues were caused by a bad SSD module). As far as testing on the ESPRESSOBin: Unfortunately the first one I ordered is already in production -- One of the reasons I wanted the SSD was to provide a little bit of high speed swap without chancing killing off an SDcard. The board its self runs like a champ and it is easily my favorite headless board I own. While some of their documentation is lacking. it does seem like they actually spent some time thinking about the board and creating docs which actually teach(force) you to compile your own kernel and use the USB to serial console and some things other board vendors don't really make you do. I have enjoyed the experience of setting it up, learning the in and outs and working with it in general, so far (other than this issue with m.2). Now, I have another ESPRESSOBin I had ordered, which they said would start shipping 'soon' so as soon as the second one arrives, I will make OMV my first test with it. Sorry I can't be more helpful right now. Maybe if I can afford some downtime of the appliance its running this weekend I will see if I can test, but I won't make any promises at this time. @tkaiser thanks again for taking time out to answer my questions as well as all the time and hard work you put in to keep Armbian the awesome distro it is! Cheers!

I had purchased both the M.2 and a PCIe adapter: here and here and this is what I was trying to use. For whatever reason it won't register in the slot. Also, I checked the kernel I compiled and I included: # CONFIG_SATA_AHCI is not set So this was not the problem. I am assuming something needs to be changed to make it notice it as PCI-e (mSATA) instead of SATA. To avoid pulling out my hair in frustration I just purchased a M.2 to SATA adapter for another 5$ and will likely just hook it to the ASM1061. If you do come up with any ideas you think would get the m.2 working in the PCI-e adapter I am all ears though! Cheers!

@tkaiser Actually it may not be a PM, I got the following and it works: http://www.ebay.com/itm/232272531643?_trksid=p2060353.m2749.l2649&ssPageName=STRK%3AMEBIDX%3AIT Seems I wasted 22$ on the 32Gb mSATA and PCI-e adapter card, most likely. I didn't try lspci -vnk but lspci was not returning anything when it was inserted. I will have to swap it out and test again tomorrow and see. I was looking forward to the SSD as my rootfs Well thanks for the response! Cheers!

Hello All, I see you are starting to work on Armbian for ESPRESSOBin and that is awesome. I had a question though I was hoping maybe @tkaiser or someone here could answer for me. I am trying to use an M.2 SSD on PCI-e adapter in the PCI-e slot on the board and noticed this doesn't work. A SATA port multiplier works just fine, however when the SSD is installed it seems it can't find the drive device. Now in reading I saw that on the Clearfog it was necessary to rebuild u-boot ( per Here and Here ) to accomplish using the SATA drive because the SERDES lanes need to be reconfigured. However, this is where I run into a bit of an issue -- In this case u-boot is on SPI NOR and from what I can tell Globalscale has not provided links to u-boot source for the board yet (that I could find). As such, I am wondering if it is actually possible to accomplish using an SSD in the PCI-e slot like I am attempting and if so how one would go about finding/patching u-boot and writing it on the SPI NOR device (or possibly boot from SDcard)? I appreciate any feedback on this that you can provide as I would love to get this working. Thanks in advance! Cheers!

This looks awesome and I know there are some other excited people here: https://www.lowendtalk.com/discussion/comment/1971180/#Comment_1971180 where I cross posted this post. Let us know when you start your campaign I know there at least a few people who would like to contribute for this Cheers!