TonyMac32

tinker.dtb is not the dtb used with Armbian, the reason being twofold, firstly the mainline dtb keeps getting edited, and secondly the 4.4 vendor image uses rk3288-miniarm.dtb, so what I've essentially done is create a dtb from the mainline one that includes various fixes/adjustments without wondering if the next kernel patchlevel is going to break it, and avoiding renaming everything from the vendor/scripts. I have to confess that I'm not 100% on how the armbianenv.txt plays into things, and haven't tried swapping out kernels for another.

Human nature.

I'm not sure that gets you anywhere, the micro-USB on the board is still an unknown and contact resistance will be higher than anyone would want.

Circling back on this one, I've had quite a lot to do around the house with winter approaching, here in a few weeks it should settle down. (Just in time for the holiday season here in the US...) @Myy, thanks for the info, I will attempt this with the DT rather than the explicit code. I might drop a line to Wzyy about it too, since they are now using DT overlays on their kernel. What this means is that, for now, this would have to be enabled via editing the DT file by the user after I get it working in this manner.

That button may put the board into bootrom mode, which I think you are leading up to.

Well that's uncomfortable...

Rockchip has done something a bit on the odd side, so I haven't gotten the patch up to r13p0 to take for the default kernel yet. I'll keep working on it, and then I'll turn my attention to the rewrite of the DSI driver for the Raspberry Pi display, as the ASUS driver is...

### Group membership of dan : dan dialout sudo audio video plugdev systemd-journal netdev bluetooth docker Was docker installed at the same time the issues appeared? 21.620963] docker_gwbridge: port 1(vethe7075d6) entered forwarding state [ 21.621367] docker_gwbridge: port 1(vethe7075d6) entered disabled state [ 21.797479] eth1: renamed from vethc6ce16b I have not tried Docker on this image, @Igor could this be related?

No, there is, it's release r9p0, which is becoming difficult to find the userspace portion of. That's quite different from there being none, you just happen to be the first individual to voice the difficulty. I am reviewing the options for patching it to a level even with Rockchip. Adding display resolutions: I have not attempted it, it is a bit involved, I can look at it after getting the Mali updated. Touchscreen: the Asus driver is garbage. The rpi driver is incompatible. I have been able to compile the tinkerboard kernel with the Asus driver, but it written so terribly it breaks other rk3288 boards that share the kernel. Otherwise everything in 4.4 but Bluetooth works on the mainline kernel build 4.13, to the limits of my testing. At the moment the kernel seems to be coming up short for your needs.

No, 4.15 doesn't exist yet, I pulled a patch that is scheduled to be included in a future kernel. I apologize for any confusion. I've moved multi-GB files with this image, that's the only reason I'm curious. the armbianmonitor link will provide basic info about the machine and dmesg info if you provide it.

https://docs.armbian.com/ There you'll find all sorts of good info.

I'm not sure this carries over to the s905x from the s905, as the s905x can only officially go 1.5 GHz in the first place. If he has time, @Neil Armstrong may be able to answer better, I don't know all of the differences between the C2 and K2 GXBB and the Le Potato GXL. I haven't seen this issue on my board, but of course I haven't done too many long-term tests. @NinjaKitty, are you using the latest kernel image? File download was the simplest way for me to trip the memory fault associated with The board didn't typically die immediately after the hang, it took some other activity first. If you can give me the output of armbianmonitor -u maybe the fault left some evidence. My Le Potato was left 24 hours without incident last night, I will repeat but give it some sort of activities to see if it fails.

OK, root@tinkerboard:/sys/module/mali_kbase# cat version r9p0-05rel0 (UK version 10.1) This is 5 revisions out of date for Rockchip (r14p0) . Also, that mali 400 stuff shouldn't be in there, it was in the kbuild but not in the kconfig [edit] I seem to be blind, it is in the kconfig [/edit], @Myy correct me if I'm wrong but they should not have any interdependent code, right? I pulled it out and it built fine and I get the module. This may take some work, unless you can get the r9p0 userspace I wouldn't expect an immediate quick fix, I will get to work on it though as it's useless to anyone if they don't have a usespace driver.

Hmmm, [ 2.476623] I : [File] : drivers/gpu/arm/mali400/mali/linux/mali_kernel_linux.c; [Line] : 389; [Func] : mali_module_init(); svn_rev_string_from_arm of this mali_ko is '-5396f8a', rk_ko_ver is '5', built at '17:24:43', on 'Sep 21 2017'. [ 2.477004] Mali: Mali device driver loaded [ 3.350314] mali ffa30000.gpu: GPU identified as 0x0750 r0p0 status 1 [ 3.355880] mali ffa30000.gpu: Probed as mali0 OK, so it probes properly but a strange loading message. I'l take a look, but I'm not sure what's going on.

I had an HP Jornada 720 and an NEC MobilePro 900c. They were cute, but really the only use was word processing, email and excel sheets for lab work. I will say hands down having a keyboard is 100000000000000000000000000000x better than not, so no, I would not buy another tablet at any price, I already have an e-reader. ;-) [edit] the NEC supported some USB devices like mass storage. Came in quite handy.

Please post the result of "sudo armbianmonitor -u"

I have not tried over HDMI. The audio out can be enabled by setting up the proper output, there are some posts about that earlier in the thread. The caveat is some random noise output that is pretty bad, which I haven't had opportunity to figure out so I haven't enabled it.

The Arm Trusted Firmware memory issue will not be fixed in the 4.14 LTS kernel, which is a bit curious, it's a pretty significant flaw and renders the Meson-GXL family of boards to be little more than paperweights. I glazed over the bit where it's queued for 4.15. Glad I didn't hold off patching Dev. @balbes150 might be interested in this as well. It's a small patch, so not a terrible tragedy, unless you don't know it exists...

Thanks @martinayotte, I'm operating from cell phone right now, a storm took out my power... I'll check these when it comes back if it hasn't been done, it will need added to the Meson64 as well, I would expect.

@Minty I haven't run into that issue, I can test it later (power outage at the moment) @badrobitsame basic message, I've not had any permission issues with Wifi, have you done anything specific with the image before trying to use wireless? Did you have any issues creating the default user, use ether to burn the image, etc?

@fredjedimaster Tido is just pointing out that we honestly don't know what DietPi is doing with their distro, we certainly aren't the ideal help. Obviously the Fiat dealer is better at fixing Fiat's, for example. They don't have any of the ridiculous, expensive, non-standard, failure-prone "triple square" bolts Volkswagen loves so much... ... But I digress. There are several differences between the systems in question, making this community less than ideal for the question you're asking. If you can't get help at DietPi (which I would assume you could), try our distro and see if you get different results.

That's the one, weird little sheep and all.

Interesting. You only have to do the export once in a session, it's so you can reference the displays via the console. My "monitor 1" is an hdmi --> DVI adapter on the end of an hdmi cable, so unless the cables are strange I'm not sure.

Please share the results of: export XAUTHORITY=/home/$USER/.Xauthority export DISPLAY=:0 xrandr The output of mine for example: Monitor 1 plugged in: root@lepotato:~# xrandr Screen 0: minimum 320 x 200, current 1920 x 1080, maximum 3840 x 2160 Composite-1 connected (normal left inverted right x axis y axis) 720x576i 50.00 720x480i 59.94 HDMI-1 connected 1920x1080+0+0 (normal left inverted right x axis y axis) 477mm x 268mm 1920x1080 60.00*+ 1280x720 60.00 -------------------------------------------------------------------------------------------- Monitor 2 plugged in: root@lepotato:~# xrandr Screen 0: minimum 320 x 200, current 1920 x 1080, maximum 3840 x 2160 Composite-1 connected (normal left inverted right x axis y axis) 720x576i 50.00 720x480i 59.94 HDMI-1 connected 1920x1080+0+0 (normal left inverted right x axis y axis) 608mm x 345mm 1920x1080 60.00* 50.00 30.00 24.00 1280x720 60.00 50.00 720x576 50.00 720x480 59.94

Strange, quick look and I didn't see anything. Do you have another monitor to try, I just booted that image without issue, going through the initial login now. [edit] Power cycling still yields a working desktop, my dmesg and lsmod match yours.