TonyMac32

Let me take a look. Can you SSH into the board or use the serial port to grab the debug info from executing armbianmonitor -u while I download the image in question and test?

I was pointing out you could use the serial port if you couldnt for some reason ssh. Thank you for the info, I'll look over it. I use Putty from a windows machine, it allows copying/pasting.

Got the box off of my friend and popped it open, it's a Mini M8S_II

No idea, that's been an "it just works" item for me, never had an issue. I would recommend moving to the newest nightly build anyway, a major bug was just fixed involving mainline crashes.

I will try this out then, thank you for the input.

I am currently just reusing the script that is used on the Odroid-C2 with Armbian, https://github.com/armbian/build/tree/master/packages/bsp/odroid https://github.com/armbian/build/blob/cdb4161ada4f0de2e92cb43748c5c32d0548f893/config/sources/meson64.conf#L59 It is run once during system init.

https://patchwork.kernel.org/patch/10002065/ Mainline U-boot may be a thing soon, the Le Potato board is a p212 variant.

Yes, that script runs at boot, but for some reason the fb is not taking the hint if the monitor is present during boot. The fact it is fine if you don't have the monitor plugged in and then do is a hint, but one I'll have to explore tomorrow. Tomorrow there should be a mainline desktop build available, there are no screen issues with it.

Can you SSH into the board after booting it attached to your switch? Or use the UART. Then post the link provided by issuing the command armbianmonitor -u As far as audio goes, I have not tried anything yet, with the other issues. Thank you for your observations on HDMI behavior.

Yes, these are still experimental builds, there are some scripts that need run at boot on the legacy kernel, however, they do not seem to be having the desired effect, I need to go through and more properly understand them. If you go to a terminal, login as root and execute /usr/lib/armbian/c2_init.sh it will fix the screen. This is next on my list since mainline crashes (that we know of) are fixed. Presently I get proper behavior with my Samsung HDMI monitor, but not with my HDMI/DVI adapter on an Acer. The issue is more serious than I thought if none of your monitors are working properly. Thank you for the feedback/info.

A patch I found on kernel.org coming out for the 4.14 [edit] 4.15 kernel, missing the LTS [/edit] is addressing an issue where Amlogic changed the reserved memory mapping for the Arm trusted firmware. Unfortunately this wasn't reflected in the kernel: http://lists.infradead.org/pipermail/linux-amlogic/2017-October/004860.html This addresses the "External Abort" error, and in my testing so far appears to have cleared it up. I had been able to recreate this failure 100% by moving a 2 GB file from my file server to the SBC, it would lock up around 1 GB like clockwork. I've moved several movie files to and from network storage, while playing a file, no problems. This has seemingly fixed my kernel crashes on the next 4.13 kernel, I have added the patch to the build system. I will add it to dev as well, for anyone who builds their own. Thank you @Neil Armstrong

I can't personally help you, but this topic should be in the TV box subforum, there is an S805 topic. You'll find a lot of info in there. @chwe

I power directly over GPIO for that reason, this board was simply not designed well power wise. I also put a heat sink on the RK808 PMIC, that little chip gets smoking hot when under heavy load.

I have that issue with USB--> SATA on my XU4, I have an older JMicron USA Technology Corp. JMS539/567 SuperSpeed SATA II/III 3.0G/6.0G Bridge

I'm afraid not, and if there were you would still have to compile the Rockchip MPP and video player.

Sound isn't really that bad to enable, but last I checked it made some awful noises. The short of it is that ASUS/Rockchip decided not to use the on-board audio of the SoC and instead used a USB codec that I can't find any drivers for other than "Generic USB" Certain audio sources output horrific noises, so I never changed the settings to enable it by default. To be fair debugging that completely slipped my mind as I never have a chance to use the thing as anything but a test box. Let me look around for this, it is a giant hole in the side of the only real use case for this board...

https://github.com/armbian/build/blob/bd86656819af402a8d301d823dd76e8877ca809b/config/kernel/linux-rockchip-next.config#L3790 The driver is built in.

@botfap the armbianmonitor output will have everything but the I2C-specific info, for future reference. It's pretty handy. @dragonlost I had this open on my phone and didn't see your edit to the post, sorry about that. Thank you for the additional info.

Is your RTC attached to GPIO 3 and 5 or GPIO 27-28? 3-5 are I2C1, 27-28 are I2C4 Just a sanity check.

Please post the link provided by issuing armbianmonitor -u

Quick question, does anyone know what a Trongle Seguro X4 actually is? It is supposed to be an S905X, but I'm guessing it's someone else's design rebadged. My friend has one and it's crap, before tearing into it I wanted to see if there was anyone else unfortunate enough to have this mystery box.

There is a specific thread for the reboot issue, I will answer here for now, perhaps an admin will move this reply and your question to the appropriate thread. I know nothing about the Z28 box, except that it makes me think of a Chevrolet Camaro . Only if that box is using the RK808 PMIC will this even potentially be applicable, I'm assuming you are speaking of the box rebooting from SD card hangs? I would personally be careful, it's my understanding that the issue with the Tinker Board comes down to poor design, if it's based on a reference design than perhaps that issue is carried over to the TV boxes, which are usually just the reference design changed enough to make it even more unstable slapped in a cheap plastic shell. If it isn't an issue, you'll find yourself hanging the kernel instead of just not rebooting. Also note I added DT platform checks in there, as this "fix" would crash the MiQi. https://github.com/armbian/build/blob/master/patch/kernel/rockchip-default/120_workaround_tinker_board_reboot.patch https://github.com/armbian/build/blob/master/patch/kernel/rockchip-default/135_tinker_boot_fix.patch Are links to the patches for kernel 4.4. Similar patches exist for the current mainline (4.13 and 4.14 RC as of this post)

Yes, Although I haven't done any real testing along those lines as yet, and the device would have to be supported by the kernel/Bluetooth stack. Google should be of some help there. Also remember the I/O bottleneck through USB, all 4 ports are shared through a hub, so bandwidth going to bluetooth will be taken away from whatever else you may be doing.

Basic status update here (31 followers of thread) All mainline kernels support wireless All kernels reboot properly Mainline kernel HDMI hotplug now supported

Wow. Also, realizing it's been too many years since I spoke German... Is this saying they got that throughput with the included antenna? Did they have a satellite dish on the AP?