TheLinuxBug

Okay, it seems I missed something; supposedly the Orange Pi 0 +2 H3 image does boot on the NEW Sunvell (R69) H3 2Gb Ram, 16GB Rom image (NAND will not work obviously). However, it boots without USB, ethernet, wifi... basically anything but HDMI and UART. So obviously need to get fex figured out but I guess I at least got it booting. Still looking for any suggestions from anyone that has it running well already. Will update as I make more progress... @Matthew Hodgson Please realize there is 2 different R69's now, the old one, yes you could run almost any image and the Beelink X2 image worked, so did H3Droid out of the box. Problem here is, this new box is not the same. It uses NAND storage and it seems has some very specific configurations needed in the fex which are custom (thinking possibly very low DRAM settings or some specific setting in the fex that is only available in the OPi Zero +2 image). It is either you are thinking of that box or you got a different revision as I spent hours trying to get different images booting and the only success I had was the OPi Zero +2 H3 Armbian image and that only works somewhat with most of the peripherals missing. Since I am still working to make it work with H3Droid, at least that is my goal, I welcome any feedback which may help and will be sure to update here as I make progress. Cheers!

You must have some weird SDcards, cause on the old R69 I had no problem booting at anytime from and SDcard. And I did a lot of booting while I was testing H3Droid. So it seems maybe you need to stay away from those no-name brand SDcards. This however has no effect on the new box. I have been testing and am yet to get anything to actually boot. I did notice in the other thread someone mentioned the OPi0+2 uboot seemed to partially load, so may test that later. Cheers!

Well, I have been working on trying to get the new Sunvell (interestingly it is still labeled R69 but not marketed as such) ( it is actually an H3 with 2GB of memory and 16Gb NAND) working... already wishing I hadn't purchased it. First off, NAND sux ass and has nearly no support outside of proprietary drivers for Android, so don't think much will be happening with it. Secondly, while I can see it will boot from SDcard, the U-boot fails much like you have shown. Which I assume means that there is something lacking in the fex that needs toggled, or even worse I have been wondering if they burnt the secure fuse on this so nothing unsigned can be booted. The latter is what I am leaning towards, but have no way yet to tell. Has anyone gotten Armbian yet booting on this new version of the board? Also posted over in a bit earlier which looks to be a post specifically on the board. Cheers!

I finally for some stupid reason got one. All I can say is unless you can perform some magic I don't think this is running anything but whats packaged. The fun part, and I don't know if this is some mid-production change, but even if I have UART hooked up, all I can do is watch it boot, I can't interact with it (U-boot). Additionally, it appears that if you have any SDcard in the slot at boot time, it will try to boot but freeze. The from LED light will not come on, it just sits dead with an SDcard in it. Haven't tried to FEL boot, not quite sure directly how to get to FEL, maybe it will read a FEL boot SDcard, not sure. Effectively though, can't boot from SDcard, I am almost convinced its they are using secure boot (burned eFuse?) also, but I can't confirm: https://paste.ee/p/51PcB They outdid them selves this time, a gorgeous piece of trash that is statically set to 1Ghz per core anyways because they can't afford a cooling solution, so really, the H2+ would have been the exact same here pretty much (haven't pried off the heatsink yet to confirm, would take bets its actually an H2+ under there). All you gain here with this version is a headache. No 'usable' eMMc (NAND instead), no way to boot sdcards that I found yet and having access to UART is worthless for u-boot, but you can access console on Android that on the box and you can 'su' to root. It looks like they are using killing cores again as their thermal solution as cores keep being killed left and right... [ 1675.588747] CPU1: shutdown Regardless of the SDcard I try, I get some errors. The following is our default H3droid u-boot and this is the output on UART: U-Boot SPL 2017.07-00494-g19d1f1a-dirty (Nov 17 2018 - 16:17:38) DRAM: 2048 MiB Trying to boot from MMC1 ** First descriptor is NOT a primary desc on 0:1 ** Booting from an Armbian loaded SDcard results in: U-Boot SPL 2017.11-armbian (Jun 11 2018 - 11:58:21) DRAM: 2048 MiB Trying to boot from MMC1 In both cases it Freezes right there, no other information it output and it doesn't boot. It is either lacking a valid matching fex (DT) or there is some magic missing in u-boot. What's more, it won't even boot the generally compatible-with-alll H3 boards u-boot we have for H3Droid based on OPi Plus 2E which almost every other H3 boards I have ever tested will at least post with. Also, the tag on mine looks identical to the one a few posts up so I likely have the same board version. Still not able to get it to boot from SDcard at this time, still trying.. if anyone has any thought, please let me know! Cheers!

Well, it wasn't that weekend, it took me a while but I did eventually make a blog post for it: Sunvell R69 - My adventures with a cheap TV Box Additionally, Sunvell R69 is fully supported by H3Droid but we do suggest the use of a fan for sure! Cheers!

Did you try re-writing H3Droid or Armbian to the SDcard first before trying to boot from it again? It would be odd if it isn't booting SDcard and its bootable. Cheers!

Yeah, its a bug. Just unplug and replug a few times, it will boot from SDcard.. this just happens... cheap implementation where its locked to 1.2volts so u-boot has a tizzy sometimes it seems. By default the unit should always boot from SDcard first, so either your SDcard doesn't have a valid u-boot on it, or you hitting the bug where it causes it to skip MMC cause of that voltage bug. Cheers!

Are you sure its not just doing its normal glitching, I have had cases where when it boots it actually errors and freezes sometimes, if you unplug power and hdmi for a minute, then replug it should boot SDcard. By default it should always try to boot SDcard first.. UART is definitely useful and helps, not trying to discourage you on that, just saying that is probably whats going on here. Cheers!

Actually, it dawned on me the moment i hit reply, there is an easier solution to this. Load H3ii on your SDcard, let it boot and install and boot to H3resc, once in H3resc you can spawn a shell. Once in the shell, now I want you to cd to /mnt/boot and review, you should be able to find the u-boot and fex files in this folder (/mnt/boot/uboot/u-boot-sunxi-with-spl.bin-orangepi_plus2e). Why this is important is, once you have performed the write of the Armbian image as you tried before, once it completes write the correct u-boot back in place (Orange Pi Plus 2E) from the u-boot file you find in /mnt/boot. All you are needing in this case it to replace the u-boot, that will do that for you. You should be able to use the script /mnt/boot/change-uboot (just make sure to manually update the destination so it writes to eMMc which will be mmcblk1 in this case) Cheers!

I understand, what I am trying to say to you is the image you wrote to the eMMc was using old FEX as it effectively write u-boot and fex in that image to eMMc (which lacks what you are needing for eMMc?). You may do better to clone H3Droid over (or write H3ii to the eMMc) and then use H3resc to install Armbian, then once in Armbian you could just remove the Android partitions and increase the size of your Armbian one., etc. Just a thought for you so you don't lose the u-boot and fex that work. Cheers!

That's because when you write the image (Armbian) back over mmcblk1 you overwrote u-boot and fex again (that are in the beginning part of the image your writing to the card). You should instead of doing that, use the options available in H3resc to re-size the SDcard (option #55 in H3resc) and then load Armbian along side (Option #57 in H3resc). If you are using an 16GB SDcard, resize to 7650 I think and then you should have more than enough room to install Armbian along side (it needs about 4GB and that should give you about 8GB). If you have any questions or need help just stop by on irc. Cheers!

If you get stuck you can come to #h3droid on Freenode and we would be happy to assist you with getting it working there and also help you with dual booting Armbian if needed. If you don't have an irc client handy, you can go to https://h3droid.com/chat-with-us and use the web client there to connect and chat with us. I should be in and out all evening so I would be happy to help if you get stuck. Cheers!

I believe the issue you are seeing isn't related to FEX but to the u-boot you are using instead. I am using mainline u-boot compiled for Orange Pi Plus 2E presently (I believe that the u-boot for OPi PC Plus _may_ also work). For H3Droid we compile our own u-boot so I am using the u-boot that is available from our images. You may be able to grab the u-boot being used by Armbian for OPi Plus 2E image and try it to see if it fixes your eMMc issue. For H3Droid you can use the H3ii image from our site and burn it to your SDCard and it will boot and install. Once installed and rebooted into H3resc you then need to spawn a terminal (with ethernet plugged in or after previously starting wifi) and the cd /mnt/boot/fex/H3 and then wget that sunvell-r69.bin file here. Once downloaded you can exit back to H3resc and then choose option 22 to set fex and choose Sunvell from the list. Once you have H3Droid working you should also be able to load Armbian for dual boot from H3resc and it should work for you as well (please report problems if it doesn't). This may be the route you want to take to make sure you can use our u-boot for eMMc? Anyhow, once I publish the blog article it will contain much more specific directions and steps which can be taken. Hope this helps in the meantime! Cheers!

Hello! Yes, the FEX I included above does include eMMc and I currently have H3Droid operating off the eMMc without any issues. Cheers!

Actually it will work, the only think you need is to put the correct FEX in place manually. I will be writing a blog post with the needed directions to do this this weekend, I hope, and will post it on our blog (https://h3droid.com/blog). H2+ and H3 are the same SoC just some parts of H3 are disabled in H2+ so its a bit more limited. (Some have said its likely H3's that didn't pass quality control for all cores or something along those lines). Effectively, however, they are the same SoC so they will work with the same software (u-boot / kernel). Cheers!

Hey Guys, Saw everyone bumping this so wanted to make a follow-up: This board runs entirely too hot to use without a fan attached. I have mounted a 30mm x 30mm x 6mm fan to the bottom of the case after cutting a hole to allow air flow into it: With fan it runs about 42-55c, without it can run as hot as 100c under load. Now, most of my testing has been under H3Droid (Android) , so with a smaller work load and not utilizing graphical display should allow it to run around 70c without a fan. For me it wasn't a choice as running GPU full out without fan was running things WAY too hot. (As a side note, the only reason their original Android image works as it does is it constantly kills off all cores (keeping 1 active at lowest frequency) to keep the SoC from hitting the thermal limit and freezing (while still running at 80-90c it will still run and play videos without freezing fully), where in the case of H3Droid we are trying to use all cores which isn't possible without a fan (will literally overheat and freeze under any kind of load).) I ended up using a FEX file provided earlier in this thread which works to get things working as one would expect, I have also placed it at the following link in case someone else needs it: http://phoenix.phix-it.com/sunvell-r69.bin The only downside I have found after all my testing is that you should NOT expect to use this board for 1080p (at least in Android) without weird glitching issues. It appears, to allow them to sell this for the price they are, that they are using slower RAM than would normally be used on other development boards (566Mhz 16bit) causing memory to not be fast enough to always handle 1080p without weird timing glitches. To note, the Android image provided by the vendor is also a hack job, there is no real 1080p mode that can be accessed, they fake 1080p on the 720p frame buffer (meaning you can change it in settings all you like, its still 720p) which is why no one has yet reported issues with 1080p as they are fooled into thinking it is running that way, when it is not. In Armbian as you are not using Mali, it is possible that you could display 1080p without seeing these issues, as of yet I have not tried so can not be sure. I just know that this board will not work without 'Disable Hardware Overlay' chosen in the Android developer settings on the 1080p frame buffer without glitching and when activating this option it decreases the quality of the video output but seems to work with some noticeable refresh lag in some cases. My hope is that this weekend I will get my blog post up about my adventure and showing the mods I have made to have this run reliably. I will come back then and update again. Cheers!

The issue I am seeing actually seems to only happen in 1080P resolution. It seems the thermal throttling setting that are default in the fex I have tested with are too high and the heatsink is actually getting almost scalding hot and CPU temp in Android reports 78c after playing 15 minutes at 1080p video (after disabling hardware overlay in developer options to stop surfaceflinger flickering). So something doesn't seem right. However, that said, almost everything works! Currently the following works under H3Droid: - WiFi - BT Dongles - Both USB ports - 100Mbit ethernet - HDMI - UART Console - eMMc I did drop DRAM to 528 for my testing purposes to see if it helped with heat a bit. At 720P it currently runs alright and doesn't seem to overheat as much. Pending is testing of CVSB to make sure it works as well, but I would love to work out this thermal issue and 1080p issue first before proceeding to that. I also changed the u-boot I was using from one for Plus 2E to PC Plus after reading some people had better outcome with that here, seems to work alright. If anyone has some suggestions for the DVFS settings for CPU and GPU in the fex that might help with this issue, please share! I will continue to update as I have more. Cheers!

Right now I am working on getting it working as I type this. The only issues I have right now that makes it not stable (using fex from one of the Armbian images in this thread and working pretty well) is that for some reason in the surfaceflinger (windows manager for Android) end up with weird flickering and I can detect some artifacts in video playback and though I don't have a way to test temp at the moment the temp of the heatsinks seems pretty hot to touch. I am guessing some additional changes to u-boot we use or fex is needed to fix this. If someone actually has a link/download of the u-boot being used in the Armbian image in this thread it would help me to not have to try and extract it for testing and I would appreciate it. I plan to write a article on my adventure on our blog as well once completed. (h3droid.com/blog). To clarify, I meant our current Android 4.4 based image, not 7.x. There are some people with the Android 7.x SDK but I believe is still under NDA so kinda waiting till we can get our hands on it to see what we can do with it. Cheers!

@lanefu if you would like to provide a link to your new image I would be happy to give it a test run (have the ESPRESSOBin sitting on the table in front of me)... just let me know. Cheers!

Ahh! it appears I completely missed this, which is why when I started things were a bit confusing. That is okay though, I enjoyed the challenge of investigating and getting it working my self anyhow. You learn more that way! Thanks for taking the time to put together the image, I will continue to test it on this board until I need it for production and try to provide some more feedback as possible. I do like the ability to get 1Ghz out of the chip, it actually provides a slightly more snappy feeling when performing tasks on the board than on the OEM kernel I compiled from 4.4.8 which is stuck at 800mhz. 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!

My only intention was to show it was faster than a USB 2.0 drive, which in this case I believe it does. Also, with network testing, obviously it gets close enough to the theoretical max that these numbers are at least useful to show that you can get full gigabit out of the board. Of course there are better testing scenarios and tools, and my goal originally on IRC was to discuss what testing you wanted but you have been quite busy with real life so never really got to have that conversation with you, as such I just did some generic tests to show it works and to set some general expectations. If you would prefer some more specific tests, please feel free to document the tools and tests you would like me to perform and I would be happy to give it another go! Cheers!

So it appears when utilizing the boot information from the boot.cmd I mentioned in my last post you get a completely different experience on UART as it stays up. This time it looks much more like a normal Armbian boot experience. I found however that I had to set the initrd slightly different as the one mentioned looks incorrect.. As you can see with initrd loading and correct environment variables set it even loads the serial terminal and leaves it active YAY! So from what I understand if I could find the correct jumper settings to have it boot SDcard it would probably work out of the box from the SDcard, without it you have to get a bit creative and setup uboot your self like above. To clarify I had been testing back and forth between the custom kernel and the 4.4.52-devel-17.04.2-mvebu64 kernel provided on the Armbian image, this time I actually fully booted the Armbian kernel and image and it actually has provided access now to cpufreq and a few other things I wasn't seeing on my custom kernel and is exposing 1Ghz CPU speed where the custom 4.4.8 kernel I made had a hard max of 800Mhz, so this should be an improvement: Will have to retest with iperf later to see if the network performance differs any. Update: from my updated iperf tests it looks like the 4.4.8 kernel actually out performs the 4.4.52 Armbian kernel, not by a huge amount but 4.4.52 seems to average around 92.3 MBytes/sec while on 4.4.8 it averages over 110Mbytes/sec. Hopefully this helps! Cheers!

So I did some more investigating about the boot issue.... What is interesting is after further review the dtb may actually already be there, and the boot.cmd which is in /boot references it as well it seems. However, the issue is the SPI uboot which is preferred by default does not read this boot.cmd file so is confused with how to locate the needed files and to boot, it required entering the variables manually. I am guessing that uboot may also be included directly on the SDcard with this image, however, there is probably a jumper setting needed to get it to boot the SDcard directly instead of the SPI on board which would likely correct the issue seen with booting the image without the need for manual interaction with uboot. boot.cmd file located in /boot I also noticed in the list of commands and arguments i used to boot that I didn't load the initrd which is shown in the boot.cmd file, I am curious how this might effect things or what might be missing. May have to see if there is any difference when adding the options to the boot command. To Note: If I recall correctly, and I will look later, I think there is a set of jumpers which you can switch to change which device is booted from... I imagine for best use of the image that these jumpers need to be set for booting from the SDcard. "Boot source selection jumpers (SPI/SATA/UART/Auto)" Cheers!

Some quick tests of a 2.5" 1TB SATA drive via USB 3.0 enclosure attached to the USB 3.0 port on the ESPRESSOBin: Iperf tests between my 2 ESPRESSOBins, both linked at gigabit: Board Running Armbian/OMV: Board Running Ubuntu 16.04LTS image with custom compiled kernel: There are probably some better tools to use, but at least this will give an idea. Looks like the drivers for the NIC in my customer kernel may be a bit faster? 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!