TonyMac32

Correct. Now that Default is working, mainline will receive this update as well. (kernel patch and testing in process) until then see the post above this one in this thread:

I will look at this tonight, I might know where the issue is. Sent from my Pixel using Tapatalk

Would it be a horrible thing to add a patch directory for a specific board, assuming we're not going to flat out refuse to support buggy boards? This way we "packetize" a csc board, or any other board for that matter. Same kernel, all common kernel issues get resolved as they do now (see Amlogic patchset) but individual board deficiencies stay with the board (Tinker changing SD driver to toggle power supply lines, I have a messy workaround using the device tree platform string keeping it from breaking the MiQi) As far as a stable branch, I like it. Roll out a patch/change to "development" branch, test it, get feedback where possible, move to stable after passing some review. Not always possible and not foolproof, but it should help prevent big and (in hindsight perhaps) obvious bugs from making it through.

I've picked up both the 5 MP and 8 MP camera module, we'll see if I can help. If not I have a pile of Pi's lying about gathering dust...

Tinker Board has it, and it works on the Default images. Might be a bit heavy-duty for your application though. There are some FriendlyARM Elec setups with a smaller screen (4.3")

Resolution is your enemy, it will have to be a very chunky looking display or an extremely slow refresh rate. @Larry Bank, you've more time invested in this arena, your thoughts?

I completely agree. I think, if a desire to be more minimalist exists, that we create those images specifically labelled as such, for devices that fit the case (OPi IoT, nanopi NEO, Duo, etc). Otherwise I don't see the value. My honest reaction to the discussion is that it fits perfectly with the "What is Armbian?" discussion. I don't think playing games to save a few megabytes fits something we really care about, it isn't really our problem if an extreme subset of users wants to pull the 512 MB SD card out of their 10 year old Sandisk Sansa MP3 player and want to put Linux on it... There are 2 main deliverables that I see: A build system for people to make their flavor of Debian for their needs, and our pre-packaged images. IMHO, if we want to make it more "lean", this can be an option available in the build system deliverable, and if we want to make questionably valuable tiny images, then we can do that in parallel with the current desktop and server images.

I am all too familiar with this kind of magic. ;-) My 4k Samsung monitor defaulted immediately to 4k, the only issue I ever had was it crashing when trying to change modes. Rockchip appears to have fixed that, as the issue is now gone.

I put in an order for prototype boards today (3), and I have components coming as well, I think Fab is scheduled for the 7th (could have been sooner but I needed at least 2 oz copper). In any case, if it works nicely I'll upload the whole mess to GitHub with an open source license on it and maybe put out a hat for appreciative people to drop change into so I can buy some beer. ;-). There are some tweaks I want to make, but that's for later or else nothing will ever be built... PCB's can be shipped in the small bubble envelopes, so there could be some options there.

Official image now includes the proper permissions and kernel.

For various hardware, JMCC's tutorial will work to test GPU/etc, for audio just load YouTube/etc. I need to wire up the spdif to make sure it works. Sent from my Pixel using Tapatalk

Packages updated at the link shared above. Rockchip appears to have corrected whatever was triggering the hdmi crash, I was able to turn it on and off by installing older and newer kernel to their latest git update. @Igor That was the only major bug I am aware of if you want to roll out a new Rockchip-default image.

Yes, I'm not sure why it doesn't take on Armbian, however Igor made a workaround that does the trick. I would like to know if anyone else has gotten the display system crash I had been getting, today I mysteriously cannot reproduce it.

I believe this is the case. suspend/resume is supposed to be a possibility, but I've spent no time working on it as yet. Now, the experimental 4.4 kernel will power down the display after a period of time.

That is a very good question. I am going to make a few test runs, meanwhile I'm trying to explore options about building. The problem(s) I have are fairly predictable: Small market No logistics capabilities. Shipping is $$$$ no one wants to spend. Time to invest in new thingies. If anyone knows of a place where you can make designs available for sale that would be awesome, I'm looking at Sparkfun but seeing an issue with Eagle being their EDA of choice, and Eagle now being a subscription thanks to Autodesk. And they'd probably not touch a GPIO power hat for obvious reasons. I'll probably have "do not use" written into the silkscreen, and the bottom copper layer. I am reviewing open source hardware licensing as well, my intention is to "make cool stuff", not to "hoard cool stuff"

Yes, I think you need Mali-T600 + https://community.arm.com/graphics/f/discussions/3481/mali-400-gpu-s-opencl-support

Then the kernel must be older than the update. I patched in a rename of the soundcard I/O channels to make it match ASUS and make sense (spdif, headphone, BT VoIP). Let me get back to you when I have access to my machine. Worst case I'll upload a deb for you to install the new kernel if you can't build yourself. Sent from my Pixel using Tapatalk

The image hasn't been updated yet, the changes are primarily in asound.conf and default.pa, which don't get touched on package upgrades. If you have a kernel dated after my update, then you can modify those with https://github.com/armbian/build/blob/master/packages/bsp/rockchip/pulseaudio.txt *Insert in where it lists modules* and https://github.com/armbian/build/blob/master/packages/bsp/rockchip/asound.conf *Copy/add depending on if you have one or not* Sent from my Pixel using Tapatalk

Yep, that's the one. I followed Da Alchemists instructions for the orange pi on the nanopi neo with success, made a how-to on my blog. Sent from my Pixel using Tapatalk

Sun Feb 25 22:17:58 UTC 2018 | Le potato | 5.34.171121 | arm64 | aarch64 | 4.13.14-meson64 That is one of the early experimental kernels, the 4.14 kernels using the Bay Libre patchset have solved the issue. I somehow doubt LibreELEC is based off of mainline linux, probably either 4.9 or 3.14 since the hardware acceleration isn't currently in mainline. Part of the problem is linked to LPA issues and the other to EEE: https://patchwork.kernel.org/patch/10142531/ https://patchwork.kernel.org/patch/10102343/ For Armbian an apt update/upgrade should fix it, as long as you can stay connected. I'd use a wifi dongle if you have one. There are quite a few other updates in there as well, such as drivers for the audio subsystem.

on Armbian please give me the armbianmonitor -u output link. This was a significant problem on older images, it should be fixed now, but if there's something new...

Thanks Igor, I see I have more reading to do about the available options in the build system...

Mine is root=/dev/mmcblk1p1 rootwait rootflags=data=writeback rw rootfstype=ext4 console=ttyAML0,115200n8 no_console_suspend consoleblank=0 fsck.repair=yes loglevel=5 net.ifnames=0 unless HAm has changed something, but that shouldn't matter as I see the same syslog complaints: Feb 22 06:49:55 localhost systemd[1]: serial-getty@ttyS0.service: Service hold-off time over, scheduling restart. Feb 22 06:49:55 localhost systemd[1]: Stopped Serial Getty on ttyS0. Feb 22 06:49:55 localhost systemd[1]: Started Serial Getty on ttyS0. over and over. Extra tidbit: crw--w---- 1 root tty 4, 64 Feb 23 22:17 ttyS0 crw-rw---- 1 root dialout 4, 65 Feb 23 22:17 ttyS1 crw-rw---- 1 root dialout 4, 66 Feb 23 22:17 ttyS2 crw-rw---- 1 root dialout 4, 67 Feb 23 22:17 ttyS3 I'm a bit confused as I haven't done anything with the tty's on this, other than allowing root login via ttyAML0.

It is ttyAML0 on these kernels, I had to check and make sure something didn't sneak through in the boot command line. So far I'm not sure where it's coming from, /dev/ttyS0..S3 are present, so systemd is trying to do its work. @Da Xue I don't have one of your images running, could you verify this isn't happening on it? I'll dig into my u-boot next, but I don't think that's where it's coming from.