TonyMac32

Ja. Also, is there a way to get all the formatting buttons to show up on a smaller than 1080p monitor?

I have a RP1 2 with HifiBerry Dac+ Pro Running Volumio, so yes, I understand. I also put together an MPD player on a NanoPi AIR with the FriendlyARM DAC, I believe that blog entry is linked on the FriendlyARM site. (Very simple, and used Armbian before I started contributing) My only thought was, looking at the pile of SBC's I have, the RPi is the most expensive one I would ever use that way. Now, others may wholly disagree, which I can completely understand. Also, having better multimedia support on Armbian? A definite win. I picked up a Khadas VIM, by far the best vendor Android distro I've used so far. No heat sink though out of the box is a concern, no matter how cool the S905X seems to run. (I'm too cheap to buy a Pro)

Interesting. To your point, their build scripts look exactly as you describe, they multistrap the debian rootfs, then modify what they need. Sounds familiar somehow... I can't possibly see how these projects can't benefit each other, although I do wonder why they care to support such expensive SBC's... (NanoPi Air + DAC is still 1/3 the cost of the Tinker, for example)

*Please* use the google search feature in the top right corner. Within seconds I found: And For USB: No. these are typically hardware limitations, also, being single-board computers, they don't always safely meet the USB specifications for all ports simultaneously (if even for one) Example: Tinker Board, RPi, etc, etc, etc.

https://www.raspberrypi.org/products/raspberry-pi-touch-display/ The board stops accepting input from keyboard/mouse/touchscreen, the circle keeps spinning on the mouse cursor, and no SD activity for several seconds to a minute or so. Then it acts normally. Wireless is not accessing the network properly, I haven't even begun digging into that. It attaches to the wifi network no problem, just no internet (armbianmonitor -u threw a firewall error, I'll copy it later). Wired works. These were not a problem on the Ubuntu I built a few days ago, with the same config down to the SD card. Sent from my Pixel using Tapatalk

Tinker Board legacy kernel now supports the 7" RPi display out of the box, just went through the first boot procedure using it on Stretch. Strange behavior on Stretch, the board is locking up for up to a minute before loading an app. It gets to it eventually, but is completely unresponsive in the meantime. I will try on another SD in the morning and grab some logs. Hmmm, network issues on wireless it would seem, stay tuned. http://sprunge.us/FVjY

Not to be a demanding troll, but would it be possible to go through this thread, create a tutorial, and stick it in the tutorial section? The parts that can be implemented can be over time, in the meantime a spoon-fed version would help those that have need of it.

Assuming I can get it (the screen) to work on Mainline, I don't see why not.

I have to agree with@chwe on this, I am in the automotive industry, not only would I be fired for such documentation of a design, there could be federal charges brought against myself and my company ending with me in jail if incorrect documentation could be linked to a failure or unexpected behaviour. Not to mention losing all OEM business, etc. It is not such an impossible task to document properly. But attacking anyone who points out factual errors in your paperwork causes animosity and people will refuse to support these products. Trust me, I am no stranger to poor documentation. But at least for the ASUS Tinker Board the problem is missing documentation, not incorrect documentation. Were it incorrect I would have immediately recommended Armbian drop all support for the board, no matter how popular it may be. Now, as an engineer I am accustomed to dealing with suppliers. In this situation, that is your role. You are a supplier of single board computers to a marketplace. That gives the user (customer) a certain amount of agency over you, the customer can require correct documentation, the customer can provide negative feedback and refuse to use your product. As a supplier it is your duty to provide a product the customer wants. In the single board computer world that is more than a board, it is also the means to use it. Your product cannot simply be defined as a board, your product is a board and a manual. And that manual needs to make it possible to use the board. The manual includes complete and correct schematics, diagrams of all exposed connections, a basic board support package (device tree or equivalent, vendor-specific drivers, uboot if not mainline, etc) As you have pointed out, most SBC suppliers in this market have flaws. But I have seen none that are outright confrontational and generally unprofessional. Do you think I don't have customers and coworkers just as disagreeable as Thomas is capable of being? Of course I do, many far worse actually. Do I respond the way you do? No, or else I would not have a job. Do I always agree with the magnitude and force of Thomas's quick anger? No. But I certainly understand it. I actually refused to reply several times during this thread because I felt my feedback would be less than professional. However, my reserved tone has apparently caused some confusion which I felt it necessary to clear up. I want to see a good competition between board makers, and the obvious benefits that come with it. So to that end I want to see you succeed. However, for that to happen you need to also compete in documentation. You have said you will, but be aware I will not engage in any development, privately or for Armbian, until there is some proof of that effort. A big step would be addressing the concerns you have heard here so many times that I'm even tired of reading about them. [/rant] Sent from my Pixel using Tapatalk

Right, my comment on eMMC is purely about reducing/removing interconnects, the primary failure point in most systems. Speed is secondary in such embedded systems. I would ideally use the SD card only for data storage, for instance data logging/etc.

Indeed you do, however it does not have "CON4" anywhere on the board silkscreen that I see, and being a 2x2 header alignment is still a bit of a question, especially when Pin1 is marked to be on the right-hand side, which is non-conventional compared to the rest of the board. Not saying anything is inherently wrong, the schematic is there, is labelled, but I for one, a senior electrical engineer, did not notice it, instead seeing an unlabelled 2x2 on the physical device. This should be on your page explicitly labelled, and probably a silkscreen adjustment made. [wishlist] Now, were it a 2x3 with 2 of those pins being a V_in.... Now that would certainly be useful and meet the approval of many. Not to mention making orientation a non-issue as it would then be non-ambiguous. ;-) [feedback] Do the various test points exist in hardware, such as the "TV-out" (TP8?)? If not they need removed, simply because you are referring to the schematic as an ultimate resource (as it should be) That said, TV-out is a Pi Zero feature... If you are open to a feedback, I would say a good variant would be one of these without wifi, but instead with the additional USB's available via header, a position for a barrel jack or direct-solder power input, and an eMMC.

Well that is certainly interesting, can we get a pinout of that?

Well, what is that header, it is not documented.

I've added RPi 7" DSI touchscreen support to the 4.4 kernel, I will work on patching it into mainline as well, but no guarantee, it is not the cleanest of drivers (requires modifying the dw-mipi-dsi.c file), and this patch is MiQi safe. This would have been done earlier, but I had to make sure it would work by declaring the hardware in the device tree instead of explicitly in the kernel source. (and make sure it didn't break the MiQi) As it turns out, I was incredibly overthinking the problem, cheers to the Linux kernel devs. Tested OK with this configuration: Tinker with DSI Display Tinker with DSI Display and HDMI display (displays are "on top of each other" on first boot, drag the smaller display around in the desktop settings and you have an extended desktop) Touchscreen driver is not robust against this configuration. It tries to cover the full extended desktop. Tinker with only HDMI (no ghost devices/errors/crashes. Tested to be sure the drivers could cope with not finding the hardware, as the device tree entries are still there) MiQi (as it does not have the DT entries, merely a test to make sure no source/driver interactions)

OK, going into settings you can pull the two displays apart and get a primary and secondary monitor. Only bug I can see is the touchscreen, which tries to cover the entire viewable area of both monitors... So if using a second display you will not be able to use the touchscreen. Reboot does maintain the desktop configuration set. Oh, and the extended monitor has a strange rodent on it. I honestly never thought I'd have a multiple-monitor SBC, I must admit it is cool.

Alright, Da Xue says Amlogic is looking into it, I'll build another image and see if I can get your results. (I am not doubting you, I'm just curious why I'm seeing a different behavior)

OK, testing against MiQi to make sure nothing outrageous is going on, screen is working with DRM rather nicely. Plugging in the HDMI at the same time is... well unique, the 7" display just lives in the top left corner of the larger external display, and the touch feature applies to the full larger desktop. In any case, if it passes testing on 4.4 it might be fun to get it to work on 4.13/14 [Edit] MiQi is working perfectly, no issues with the entries in the Tinker DT if the screen is not connected, I'll upload the patch.

Thanks @Andro for the report, and @Da Xue for the information. I've now observed the same thing, however in my case it takes up to a day to appear, although admittedly I'm not doing server activities (I set the device up to stream an entire Youtube channel, which it did successfully overnight, setting it up where I would ping it periodically eventually *seems* to have knocked it out) It seems as though incoming requests may be to blame, rather than outgoing traffic? I'll set up a server with it and see how differently that behaves.

OK, some progress on 4.4 using device tree. Not much, but a start. [ 3.063423] tinker-mcu: tinker_mcu_probe: address = 0x45 [ 3.063440] tinker-mcu: send_cmds: 80 [ 3.115505] tinker-mcu: init_cmd_check: recv_cmds: 0xC3 ... [ 3.197508] tinker-ft5406: tinker_ft5406_probe: address = 0x38 [ 3.197774] input: fts_ts as /devices/platform/ff150000.i2c/i2c-3/3-0038/input/input0 [ 3.198446] tinker-ft5406: fts_i2c_read: i2c read error, -6 [ 3.198458] tinker-ft5406: tinker_ft5406_work: checking touch ic, countdown: 8 Basically the drivers are being loaded, but the touchscreen driver is not thrilled. I also could find nothing from the DSI system itself, looking for what I assume is a silly mistake on my part. Ah, I forgot the dsi entry in the DTS. Like I said, silly mistake. Also need to track the rockchip changes to the dtsi, it appears the renamed some things... Still no display, but at least it appears everything is attempting to load up. [edit] Small update [ 3.061366] tinker-mcu: tinker_mcu_probe: address = 0x45 [ 3.061381] tinker-mcu: send_cmds: 80 [ 3.113595] tinker-mcu: init_cmd_check: recv_cmds: 0xC3 [ 3.195831] tinker-ft5406: tinker_ft5406_probe: address = 0x38 [ 3.196727] tinker-ft5406: fts_i2c_read: i2c read error, -6 [ 3.196740] tinker-ft5406: tinker_ft5406_work: checking touch ic, countdown: 8 [ 3.303832] tinker_mcu_screen_power_up [ 3.303835] tinker-mcu: tinker_mcu_screen_power_up: [ 3.303851] tinker-mcu: send_cmds: 8500 [ 4.143734] tinker-mcu: send_cmds: 8501 [ 4.173772] tinker-mcu: send_cmds: 8104 [ 4.205022] tinker-mcu: tinker_mcu_set_bright: bright = 0xff [ 4.225881] tinker-ft5406: fts_check_fw_ver: Firmware version = 0.0.0 [ 6.894450] systemd[1]: Set hostname to <tinkerboard>. OK, I'd forgotten how creative some of the Rockchip code was. I'm getting closer, the screen is powering up at this point, but showing junk instead of image. The touchscreen driver is working, it is acting like a touchpad for the HDMI display....

@Tido surely you're not so serious as all that? I haven't had a non-16x9 monitor since I abandoned the VGA cable. The amazing amount of unnecessary extraneous noise aside, I'm glad to see EDID is functioning properly. Now, I will continue to give candy to strangers as part of Halloween. And maybe freeze to death.

So was this the Armbian nightly or the Myy kernel? I only have 720p, 1080p, and 4k test monitors, so haven't been able to test any other "strange ones"

@tkaiser sorry for the delay, I'm at the day job, so haven't had a chance to look through it carefully. Did @zador.blood.stained cover it? [edit] partially for my own curiosity I verified zador.blood.stained's findings, if component values are correct 1.1 and 1.3 volts. My knowledge of the H2/3/5 is not that great, but I would guess, reading off of the CPU feedback pin for the regulator feedback, that you could measure (slightly) higher voltages at the regulator under load as it compensated for losses (in case anyone busts out the Fluke).

Quick look, I see component values and a lot of labels, excellent. No time tonight to compared to advertised specs, but quick glance I see H3 on the schem, it is an H2+ in actuality, correct? What is the 4-pin header between the micro-USB connectors for, is it a DC in or a power button? I would love to see another way to get power to one of these boards besides micro-USB or the Pi-factor GPIO.

I feel like I already knew that, problem is I wind up building stuff all the time and almost never just update.

The "Dev" images are 4.14, but they must be manually built by the user.