TonyMac32

@Xalius

Assuming the rk3328 maskrom is similar to the rk3288, @Kwiboo is mostly correct. There are a couple magic values, the U-boot SPL, and a device tree that get located before the main U-boot is loaded, but the maskrom uses hardware block device addressing, it does not use the partition table. Now, with the SPI memory this changes. Then, whatever U-boot can see it can load after the maskrom loads U-boot from that chip (if loaded/enabled)

I have split 2 major support issues into their own threads, Bluetooth and Reboot. I have gotten Bluetooth working on nightly builds of the default kernel, you need to use rtk_hciattach on every boot (add it to startup). Next/dev kernels are still a work in progress.

Yes, if the tags can be visually suppressed, I'd be a proponent of them being mandatory.

Default kernel can now operate the bluetooth radio with the DMA disabled on UART0. Successfully connected to a bluetooth speaker and played music (it was connected as a headset, but I was more worried about it working at all). Will update patches presently.

Quick note: remove ASUS Tinker Board from "Other" board subtitle. ;-), add "ASUS Tinker Board" to Rockchip in place of "Tinkerboard" @Tido I think any reasonable discourse is worthwhile, if not immediately productive. A lot can be learned from the ideas of others, even if only about the people themselves.

There needs to be some additions made to the device tree. I have to make some changes to match current Tinker OS, I will try to add those as well. Sorry for the delayed reply, I've been tied up with other issues/home projects/etc.

*Updated 7-23* ~~All kernels should be fixed at this point, Legacy, Next, and Dev.~~ The ASUS Tinker Board has a big problem with rebooting properly, centered around the SD card power supplies. Upon issuing a shutdown request, the kernel is turning everything off , including the vmmc regulator. To make matters worse, vqmmc is set to 1.8 Volts if you use a UHS SD card, and the kernel is not switching it back to 3.3 volts before rebooting, which is required if the Rockchip boot ROM is to communicate with the device. The result is a hung board in MaskROM mode. For the Default kernel (4.4), a patch was carried over from the vendor software (quite literally tagged as "HACK" which added a shutdown routine to the rk mmc driver. It powers vmmc back up, switches vqmmc back to 3.3 volts, then delays for 20 uS or so. It works on default. 7-22: Need to add fix for " echo b > /proc/sysrq-trigger " ETA: 7-22 or 7-23 7-22: Adding device check to make certain there are no complications with the MiQi. Concurrent with sysrq fiq. Complete and uploaded. For Next/Dev kernels, however, it does not work. I don't know the full system that well, so I can't comment as to why just yet. It is also important to note that testing the patch on kernel 4.11/4.12 resulted in a MiQi crash on reboot, wheras I've had confirmed this doesn't appear to be an issue on 4.4. 7-22: It was determined a day or so ago that the issue was the mmc not being powered down before the hack happened. Now that is commanded. 7-22: Initial patch broke MiQi, myself and @Myy worked today on figuring it out, trading kernels and patches. We thought it a good idea to use the device tree platform to discriminate. Fix is now known, adapting patches and moving them from Dev to Next. Implemented 7-23: Rockchip-DEV is now kernel 4.13, reboot patch tested and works. Any expertise in this area would be welcome, I'll update this post as things go on.

Update May-15-2018: pushed today, Bluetooth patches to support bt in default and next kernels from boot, no user intervention ( "It just works" ). Thank you again to @Myy and @Jyu Ho for their work.

That extra 10/100 ethernet seems like a good place to put an HDHomerun if you were running a TVHeadend server...

Well, we don't use it, instead just putting the data where it goes without the partitions. At least the 3288 ignores the partitions themselves and is only looking for the "magic" values and bootloader

That's the "Rockchip recommended" configuration. If you look at the ASUS Tinker Board images it's the same thing. It's how they put the data where the bootrom wants to find it.

@Xalius If you would that would be great. @tkaiser Agreed, I just wanted to make sure nothing got shuffled under. The banana pi R2 post was quite enlightening, I'm being quite serious I wish I'd have seen something like that for the Tinker Board, at least then I'd have been less surprised. (The name stuck to it did it's job and I bought blindly)

Common issue binning seems like a good call, especially if common across all devices. We could have a general-purpose "You didn't give it enough Volts" collection as well. [edit] I think the H5 stuff can stay where it is because it is dev only. Community boards/deprecated: There might need to be some kind of build system adjustment to handle that, unless a "recipe" kind of approach can be taken by users to patch a new board into the build system on the fly. That would leave the official build system alone and allow people to do whatever they want with other hardware. Probably need to make compulsory "Unsupported Community Edition" notes or something. Or simply act as a place for people to link to images they've produced.

The mainlining (is that a word?) looks like it just started not too long ago, and given the 4.4 kernel is the one directly from Rockchip, and the... unique coding style I've come across for some of their workarounds, I'd agree for now. At the very least for mainline the RK805 needs supported, it's a non-start without it. If given a board I'd help support if/when the time comes, as much as I'd like to I don't think purchasing one is on my radar just yet, and it would be hard to justify having 2 SBC's that don't actually do anything but absorb my working time... ;-) As a note to Mods, should this be put in the "Board Bring-up" sub-forum?

Wireless isn't up on Tinker Board Next because the driver wasn't added to the kernel until 4.12, On Dev I connect to wireless no problem, it's one of the things I've been making sure to test since fooling with rfkill/btcoexist with Myy to try to get BT to work. For MiQi I don't know without the device. If your MiQi isn't tied up, could you verify if you have any reboot issues with the current legacy 4.4 kernel? 4.12 changes some things it would seem, or the rockchip-linux kernel is just plain that different, attempting to "fix" it the same way did nothing at all on the Tinker Board, but Myy reported it broke rebooting on her MiQi with 4.12. Researching to find another way, I'm not sure where the Kernel decides to shut down all the supplies. If a reboot issue with MiQi exists with the power supply code on Tinker (no one reported an issue, but I don't know how many MiQi people are out there), I'll have to "re-break" the Tinker board for the time being. If reboot can't be fixed properly, that's a major strike against it.

Most of us probably do some electronics along with the small computers, I've been part of "what does you desktop look like?" threads (terrible, by the way), thought I'd put up (the electronics part of) my workbench: I wasn't about to lie and clean it up before hand...

Well, I'm a cyborg, and I still run on 2.6. . I may have been grounded by the wife after I bought the Tinker Board and then had to buy another box to take up it's intended position in the living room... :-/ Getting one of these may not be in the cards unless someone has pity on me. I'm certainly more gunshy at this point, The nanoPi's went so well I got careless and wasted some money. On the bright side, I've learned an awful lot about a lot of things I wouldn't have gotten myself into before hand, and I'm glad to be learning more. Now, speaking of, time to go work on cleaning up Tinker Board messes. I need to "unfix" something that is reportedly messing with the MiQi and try out Myy's attempt at getting BT working (involves a Rockchip custom rfkill driver) And figure out if my MAC address is actually stable on the thing or not with Igor's U-boot patch. I saw more than one value, but I need to make sure I'm not just hallucinating due to distress over the general state of the board.

I typically hate trying to figure out tutorials via forum after they've been around a while, things change, comments add info or other methods, then the OP isn't maintained. Also, diagrams and images are realistically impossible in this format. My thought would be to have the OP of a tutorial consolidate all of the useful information from ensuing discussion, make a document for the website, and stuff the thread into a locked archive bin linked to for reference in the finished tutorial. Or, alternatively, have the tutorial on the webpage, and link from it to the forum thread, and don't pin it. The info is on the webpage, discussion is as-needed on forum thread. There's a ton of useful info here, I was introduced to this project due to a search that led me to @Da Alchemist's post about getting I2S working on the H3 devices. That's also what I was thinking for pre-release/specific version support threads, lock/archive them once they're out of date (how out of date is obviously a discussion point). They disappear from cluttering the forum and keeping it on point, but we haven't deleted/removed anything, all can be retrieved for trace-ability purposes. (too many years in automotive, you keep all documentation and emails forever) Community would definitely be the place for TV Boxes, I've hesitated to build an image for the UT3S because I know the resulting torrent of requests that would follow... I've been trying to get the currently interested parties to try it out themselves. If RK3328 devices are the next "thing" with the Rock64 simply being first (and IF the team decides to support it), yes, a Rockchip subforum would be ideal. I like the "How To Use This Forum" bit, of course there are ~ 400k users and only ~190k views of that . At the very least it can be pointed at, giving the user every opportunity to do it the right way, making any moderation less surprising.

This isn't helping me not want one. ;-) I'm paging through the mainline kernel support, hopefully more of these make it out of the Rockhchip patchwork and into 4.12 (like RK805 support). As it stands I think mainline support is possible, if not extremely convenient.

It is frustrating, it's also universal human nature. I sold car parts while going to college, people always wanted to buy the generic parts instead of the original equipment and then got mad when they lasted 2 months instead of 5 years. Even now working with Automotive companies, sometimes I have to explain the laws of physics and why my products can't defy them. So was it the need to moderate the posts, or the constant onslaught of said posts that caused the issue with the orange pi zero? I was thinking of a garbage collection thread that would be slightly more polite than deletion, and less distracting for devs trying to answer real questions. Example:. "Why can't my nanopi neo transcode 6 video streams simultaneously while cooking me breakfast?" From moderator:. "post moved to "collection of insane and redundant questions. See FAQ in OP of thread."

To be honest, I didn't need to talk to anyone before contributing/trying to contribute. The Tinker Board is an excellent example of a board that has some pretty severe vendor-caused support issues in general, ticking off nearly every box from some of the earlier posts. In this case I had one, I cloned the build system after following the proper documentation to set up a VM on my main computer, and got to work. I then submitted pull requests on github with my changes. I don't think a discussion about officially supporting a board is frictional to getting new devs, but I think seeing devs get dogpiled for support requests is. That was my 100% biggest concern about getting involved, the questions I simply can't answer because I'm a low-level (firmware, micros, assembly, etc) programmer, not necessarily even a well-versed linux kernel guy (learning quickly, but there is a lot there to learn). I'm afraid that's impossible to stop. "Joe SBC" will invariably try to make a $8 device do the work of a $50 device. Managing expectations is most likely more difficult than supporting hardware. While it will upset the low-information DIY-er, I think you'll find collecting such requests/feedback into dedicated "rubbish threads" that link to the FAQ and disclaimers won't be detrimental to the project. More moderator work. For supporting new boards, as long as the user community (those with no intention to develop) understands and respects that the dev users (anyone willing to code/organize/troubleshoot/brainstorm/document have final say over supporting a board (their work, their decision), then all transparent discussion is of course the preferred method. I do like the headstone method of having an OP of a thread contain the status/updates/issues of a board, then mark it as EOL and maybe lock the thread. @tkaiser, I like the OP in this thread, and considering improved moderation that would be a good way to get the information. It can be done just as easily publicly as privately, getting the weigh-in of the typical dev, I just know that sometimes I have opinions of things that may offend vendors or even users, e.g. "Well if you're stupid enough to do that, I'm not going to be any help" . I've been dabbling with websites and projects for almost 20 years now (I started young), the biggest problem I see with the free exchange of ideas that is the forum is burying data in clutter. A 20 page thread will have, literally, 2 pages of useful content. This is simply due to agreement, question, additional thought, etc. This is why Forums are terrible archived documentation/reference sources. It's very easy to blame it on the user when they re-pose questions, since a proper search can find the information, but often it turns into wading through pages of nonsense and unrelated tidbits to get the command, or parameter, or info you wanted. I believe a more constructive method involves the Forum as an idea development/collaboration platform that said information is then culled from and formalized in some manner. I would recommend something like below: For a new Board, exactly as tkaiser opened the discussion, updating as new information becomes available. Once a decision has been made by the team (I would assume a dev or two would have to more or less "adopt" the board in question for hardware support), close the thread, maybe clean it of extraneous info if mods haven't been doing that actively, and archive it as reference on a wiki, or transfer its information to a wiki and link to an archived PDF/html/whatever of the original, maintaining the conversation, but not allowing it to get buried or cause a huge amount of "pinned" topics you have to drill through to get to "live" discussions. Upon officially declaring a board to be supported, have a subforum for the board (I know, huge effort organizing), then open a discussion/debugging thread for each release. Lock that thread upon release and open a bugfixing thread, etc. Keep the last release or two on the forum as immediate reference, archive the rest as HTML/PDF/Whatever available via a Wiki page for the board. A "Hardware Support Status" table on a wiki would be ideal, just simple Green/Yellow/Red next to the supported bits per kernel, a simple visual aid goes a long way. I would include an * or <- or some other mark with a note about special patching if it's needed (WiFi on Tinker Board Kernel 4.4 as an example) "Official" Forum threads need to be consistently titled (example/proposal): [Pre-Release 5.31] Hardware Feature Request [Release Candidate 5.31] Bug Reporting [Release 5.31] Continuing Support Now, boards may come about that initially seem like a great idea, check the boxes, but which later turn out to be piles of garbage. I would recommend having a mandatory "trial period" for a board before committing to support it, no matter how perfect it might seem. (Call it "Maybe-an"? ) Again, personal experience here, the Tinker Board BT, SD power supply, and MAC address issues all require hacking up the kernel in a not easily supportable way or writing our own drivers. Some of that wasn't obvious until the Rockchip/ASUS team released the source for their kernel. In a situation like this, a discussion needs to happen concerning how to support and if/why to support moving forward. I would personally wait another cycle for the next release and see if any more mainline work is done on the part of the vendor. If not, we need to decide if something as ridiculous as making the board capable of rebooting properly is our responsibility/interest. Other boards, I'm sure, are similar. My apologies for rambling.

They are hardware I2C peripherals, so they have buffers/control registers/etc, they are not software implementations that can be disrupted by other tasks. Worst case you overflow a buffer before reading it.

Oh my, I'm going to have to agree with you on that, I looked up the sensor when I saw it was a 1-wire bus... It's a "special 1-wire bus not compatible with the Dallas 1-wire". Bummer.

Yes, it is a reflex that a hobbyist has, "to collect all the things". Especially when one looks like it should be shinier than the others. BSP's, true performance, driver catastrophes, kernel defilement doesn't show up in the advertisements for these devices. It is not helped that the "flagship" SBC in most people's minds out there is the Pi 3, a micro-usb powered usb-hub throttled VPU-constrained machine with very poor resources. Compared to that, anything with high clock numbers or extra "RAM Chips" looks like an amazing deal, people tend to take the community support over there for granted. I do like the Wiki idea, however in a less ambitious sense: We should list, with no "rose-colored glasses", exactly what the pros and cons are of each board supported, discrepancies between hardware specification and advertised capability, and recommended use cases for each board. For those use cases, I would personally require a definition of minimum requirements and recommended requirements per use case, and those would live on their own pages.