TonyMac32

Let me know the uname -a output and any errors from trying to use the ASUS software.

The BTCOEX and such used by ASUS is several revisions back and, if the Mainline work on the wifi driver any indication, probably buggy.

We could just be overthinking it, the Next download jumped from 4.11 to 4.12.3, could just be an updated module, rather than a new one.

Hmmm, no idea, that doesn't actually look like a bluetooth keyboard, to be honest, it's just popping up as a standard generic HID device. [ 1.996363] usb 1-1.3: new low-speed USB device number 3 using dwc2 [ 2.079542] usb 1-1.3: New USB device found, idVendor=046e, idProduct=5577 [ 2.079556] usb 1-1.3: New USB device strings: Mfr=1, Product=2, SerialNumber=0 [ 2.079566] usb 1-1.3: Product: USB Multimedia Cordless Keyboard [ 2.079574] usb 1-1.3: Manufacturer: BTC [ 2.083962] input: BTC USB Multimedia Cordless Keyboard as /devices/platform/ff540000.usb/usb1/1-1/1-1.3/1-1.3:1.0/0003:046E:5577.0001/input/input0 [ 2.135850] hid-generic 0003:046E:5577.0001: input,hidraw0: USB HID v1.11 Keyboard [BTC USB Multimedia Cordless Keyboard] on usb-ff540000.usb-1.3/input0 [ 2.143143] input: BTC USB Multimedia Cordless Keyboard as /devices/platform/ff540000.usb/usb1/1-1/1-1.3/1-1.3:1.1/0003:046E:5577.0002/input/input1 [ 2.195087] hid-generic 0003:046E:5577.0002: input,hiddev96,hidraw1: USB HID v1.11 Mouse [BTC USB Multimedia Cordless Keyboard] on usb-ff540000.usb-1.3/input1 perhaps if you could boot the other images that don't recognize it, with it plugged in, and do the same thing? I'm kind of curious now...

I can't tell you for sure, to be honest, I haven't done anything with external peripheral drivers. Can you drop me the link that running armbianmonitor -u gives you? My guess is the USB dongle presents a 3-wire HCI device, which I enabled to begin work on the on-board bluetooth.

Given the reboot/bt issues I haven't worked out how to make this default in the user space, it's part of the build system I'm not acquainted with. There's also a sampling issue of some sort, certain sources send horrible screeching garbage out of the jack. That's also happened to me using I2S with this board. I don't know what HDMI would do.

I've been playing with some board artwork to make a general "Pi-formfactor fixing Hat", I agree that a modified heatsink gets a bit close. I have a 10mm heatsink and think an 8 would be maximum. For a charge port, you'd ideally want to make it a colored port (red I think) so it's obviously for a singular purpose.

Rockchip Dev is now 4.13, reboot patch successful there as well. All kernels patched for those who build their own.

*High-Five* I'm testing the 4.4 legacy kernel with the emergency patch, I added all the changes we made to it so as to protect the MiQi (And I think it's just smart). I'll be working on 4.13 later today to get Dev set up. I forgot to change the compatible line in the dts, so it didn't run the code. Well, I guess that works.

Right, I wasn't sure how far into the weeds we wanted to go. If you reference my post in the Tinker Board thread, I always characterize mine by putting a minimal load and measuring the voltage there. For voltmeters, I recommend spending around $40 USD minimum for one that will function acceptably well. A Fluke is the "ideal", but let's be serious at least half the cost is BS.

Very well done, for anyone from my side of the pond, "U" is "V" for voltage. I have many French and German coworkers, so I've seen the different notations. ;-). To add some insight on some of the details, I'll do some explaining of mysteries: Power supplies have an intrinsic output "impedance", which means they will act resistively and reactively to changes in consumed current. This is why the open circuit voltage on such devices is above the spec, the supplier knows they have to overcome the internal resistances at load. As for the reactance, that's primarily an audio quality concern we can talk about later. Resistances along a transmission path can be broken down into 2 types: material resistance and interconnect resistance. @chwe covered materials perfectly. For interconnects, the same rules apply, however unlike a continuous stance of material, the electrons have to jump small gaps and navigate narrow pathways to make it to the other side, which is a large resistance. The obvious one is the connector solution itself, however a not so obvious one is the internal termination between the wire and the connector. In general, smaller wire means a less robust and smaller contact area in the termination, and so an added resistance.

The next nightly should have the reboot fix on kernel 4.12. Please test and comment.

I tested within the Armbian build system, so I tested 4.12 (Armbian Next images are available to the public via download link, so they were my first priority). I'll give the 4.13 a try shortly, although I see little reason it won't work, the problem all along apparently was the assumption the mmc shutdown would occur before the patched code was called. Now it's explicitly commanded.

I just got back to my machine after some food. ;-) I am building the Armbian Dev kernel with the adjustments, I was hoping just making sure the pointers were good would solve it, hopefully we're right and the device-tree entry works properly. I'm safe in assuming this kernel does not crash the MiQi? @Myy It worked! I'll update the dev patch accordingly, and to be safe test on the 4.4 as well, I don't have the sysrq reboot done in there yet, I've been gun-shy due to the potential MiQi issues.

For Pi form factor boards I've been using a 25 x 50 mm aluminum heatsink available on Amazon, top left in image.

My board finally escaped customs, I should have it late next week.

*EDIT* I'm holding "Dev" back at 4.12 until we get this reboot tested. @Igor, if you can try it out on your MiQi and make sure there weren't any unexpected collateral damages. I don't know who else besides @Myy has one. "DEV" is now 4.13 and is having build errors. I'm going to strip some patches and see if that takes care of it. Meanwhile, the patch will work on "Rockchip Next" for anyone able to test it's effect on MiQi. Once we verify MiQi is OK, I can stuff it in there and let it go free. I added the "mmc_power_off()" call to the platform shutdown hack, to make certain the card was "dead" before restarting the supply and resetting 3.3Volts and, well... It works! So I will put the patch into Dev, if MiQi owners can test if it breaks then we'll have to do something else, decided by the build system wizards. ;-)

Emergency reboot. I haven't applied those to the other shutdown path yet. I was researching the shutdown process to see if a cleaner method could be conceived of... I need to save up my pocket change and get an oscilloscope so I can do some better hardware debugging. So I'll get back to you in 5 years or so... :-P

I used echo b > /proc/sysrq-trigger to trigger reboot on 4.12.2 with the ugly hack installed, and it worked. Without the hack it does not. Let me see if I can apply it to the normal reboot process.

I will take a look, thank you for the link. I was hoping to be able to use their repository instead of the snapshot, but given no other option... I have also reached out to Amlogic to see if they'll reply concerning the git repository. I think I'll follow your lead using the July release. http://share.loverpi.com/soc/amlogic/buildroot/

Thank you @Myy, I compiled the fix into a Dev kernel, but haven't had opportunity to test yet, I'll be doing that in around 6-8 hours after work. This is where I complain about wishing I knew more so we could simply not shut off the vmmc and set vqmmc to the proper level without it being an amazingly sketchy hack. As for the commercial RK3288 devices on the market:. They boot from SPI and/or eMMC, not from SD. The SD is handled as a peripheral drive, not as a boot drive by the kernel.

I would prefer to implement device tree overlays, however I'm unfamiliar with how it works and would hate to break something. As far as the GPIO library, I have been pondering whether Armbian should adopt a specific library and implement it across all boards for consistencies sake. Obviously every board has different I/O, but some commonality would be good, and having it available in the configuration utility would be even better.

Has anyone had any luck cloning their repository as described on http://openlinux.amlogic.com/wiki/index.php/Arm/arm-Kernel_Info/Kernel4.9 So far it just keeps timing out on me.

Patches are being pushed on patchwork for mainline support of Le Potato as promised on Kickstarter. https://patchwork.kernel.org/patch/9845599/ At this rate it will have a better mainline device tree than the Tinker Board (Armbian's NEXT and DEV DTB's are my mashups using the 4.4 device tree from "ASUS" and the Rockchip Linux github)

As the NEXT image has moved to 4.12, I'll be moving the wireless patch over. Sorry about not catching that sooner, the switch killed compilation due to the Mali driver. There still won't be Bluetooth or reboot fix, I'm afraid...