TonyMac32

I like this, but it does mean something like multiple branches being used. Then people who use the build system can use the stable branch without being (too) worried. This is possibly a law of nature: "Jack of all trades, master of none" I've been asking for feedback for 3 (4?) days on the Rockchip kernel for Tinker, have even now provided a kernel package for download, and nothing. It doesn't get a lot lower hanging than that for the even mildly interested, 200 views, no downloads to date. (I think you've found my frustration)

I think there are some server issues on the git repo, I experienced the same thing last night trying to check the sources for u-boot. Also, for general instructions, docs.armbian.com

MiQi tested and booting, however eMMC not showing up, checking config

the build system packages the kernel/headers/dtb as debian packages, they can be installed that way

I'm afraid there is not, eMMC requires a few changes to files that I haven't worked through, and I don't have an eMMC for the K2 available.

The build system is only targeted to run on x64. This simplifies the load of so few supporting so much.

For the RK3399 board, firstly, nice price point. Nextly: I'm assuming an RK808 PMIC, so that is maturely supported in the mainline kernel. SPI NOR is again a great addition to put the bootloader in there. The available wifi module for rtl8723bs is obviously supported, by both mainline and the rockchip wifi subsystem they have in their 4.4 kernel. And, teasing the AI SoC just discussed during FOSDEM... ;-)

The Tinker "Get Attention" thread.

OK, in a last attempt, ***use at your own risk***, and only for evaluation purposes. debian packages for kernel/bootloader/etc I also noticed the one up now is claiming to be "4.4.112", but there is a failed incremental patch after I merged the current build system to get mine up to date. root@tinkerboard:~# lsmod Module Size Used by uas 20480 0 zram 28672 4 lz4_decompress 16384 1 zram lz4_compress 16384 1 zram 8723bs 1253376 0 On resolution change from 4k this kernel still gets DRM crash resulting in oops, going to do some debugging, if anyone else has seen this let me know.

It should. It should also be theoretically possible to use the mpp platofrm for video decoding as well, something I haven't yet tested, along with device tree overlays (see most recent commit). I haven't made an image because I don't want an explosion on my hands, but a show of hands who can test that wouldn't be able to build it?

Our u-boot is set up to load that file from ext4, so there will most likely need to be some modifications to run from the eMMC. I can probably look a bit more closely later today while I'm waiting for feedback on the Tinkerboard default kernel.

The text version is boot.cmd in the image

I have not done this, I'll need to take a look at it once I get a bit further on this Rockchip kernel for Tinker.

At $60 that's a definite want. At $110 you need to show me why I need all those connectors.

https://github.com/armbian/build/blob/2c049615d55a1e7f88fe58e2061c299f5a4ac3b6/config/sources/rockchip.conf#L19 ------ I mostly agree, but it is a regression from current capability.

I started doing that for a few reasons, one was professionally we always had a status cover sheet for project activity, a summary of activities todo and complete and a "gate review" scoring project maturity from 0 to 100% based on key requirements (automotive stuff, so customer approval, validation testing, IMDS, PPAP, etc) The other reason I took to doing this way was being a noob in the world of phone ROM flashing, the threads I always liked the most kept a running status in the OP with the latest links. Otherwise you have to search around for something that's been referred to 100 million times so text search is terrible, only to find the project dies a year ago and people have just been asking questions every 3 days since then, mostly to cry about it not working out. I think it's helpful more than not for a few reasons, one is keeping myself organized, the other is, a new user will hopefully look at the OP, then a lot of questions can be avoided. If they don't and ask a "dumb" question, I can simply point them at the OP. I have had a few people provide help. Botfap with the HDMI hotplug that I think is relevant to any 4.x kernel HDMI situation, I've gotten some feedback now and then mentioning that things needed it, etc. And some people do just leave well enough alone until something is said, like with audio, I got a question every few months about it, with the post there has been some typical and positive interaction.

Would be nice to get some feedback what others think about it. Perhaps IRC as well, It's usually 00:30 here when any of you are waking up, and after the day job and time with family, you are all asleep again. ;-)

Hello everyone, I've begun working to target the Armbian Legacy Tinker Board build to the Rockchip kernel. There are a list of reasons why it needs done, including some relatively large differences between the current kernel's code base and the Rockchip kernel (making it hard to patch with bugfixes/etc) and inactivity on the part of the vendor of that kernel. There are also reasons I am preferring to use the Rockchip kernel rather than the ASUS kernel. First and formost is the need to also support the MiQi. The miniarm branch of Rockchip and the ASUS kernel have board-specific fixes written in such a way as to not be friendly to other boards. I've decided it would in fact be easier and more reliable to use the Rockchip kernel and apply the needed fixes in the most appropriate way for our project, as we have different needs than a board-specific vendor kernel. This is a build-it-yourself situation. This is a fork of the Armbian build system using the Rockchip kernel source from https://github.com/rockchip-linux/kernel Things that work and are tested: Wireless Bluetooth (via the typical hci attach method) 4k/2k/1080 Raspberry Pi touchscreen Compiles with gcc 7.2.1 [resolved] Mali is somehow only building for Android, "Mali for linux" throws error during build. This has been clarified, I reached out to Rockchip, this kernel config is simply to allow using older drivers with Linux if so desired. I don't see immediate reason to desire, so good. [resolved] HDMI Blanking out on change from 4K to other resolutions. Somehow switch to 4k is ok. Rockchip adjustments to drivers fixed this for my use case, waiting to hear other feedback VPU/Mali tested/a tutorial by @JMCC Things not worked out: RGA/VPU/etc are untested/unconfigured/incomplete. Not tested 100%, but working (RGA uncertain) Other things I'm sure. What is needed are people able to test the kernel and determine if it is able to be rolled out. The kernel presently used is no longer maintained by the vendor, and split from Rockchip too long ago to be able to patch it appropriately.

The Tinker Sound thread is actually showing the mainline I2S is not working. I think a look at the ASUS 4.4 kernel may be needed in this case. My test early on running a 5102A I2S DAC from the GPIO was with the 4.4 Rockchip-curated kernel.

I like that as well, I wasn't sure how far we would want to go along those lines. That's what I figured, and was more or less what I was thinking.

Kodi can't explain it either, so they also wind up handling all sorts of questions about ridiculous hardware. That's really it in a lot of cases, but sometimes it goes deeper, for example the RK3328 doesn't even have HDMI out on mainline (I keep meaning to patch our build, I found patches to add it) Some boards don't have frequency scaling/etc. I agree with this. I think most people will understand apt and if not the community contributors who aren't coders can write little how-to's as far as newbies with SBC's are concerned. I see it as a benefit to move the burden of this from the developers trying to make the images fool-proof to the advanced users providing guidance. I recognize this depends on people stepping up, there are only so many @Tido's and @chwe's available. ;-) As @chwe properly summarized, I think a template for board support would be handy. Not that it was terribly hard to figure out, but I made a few mistakes along the way anyhow... Perhaps a kernel config including all the "Armbian-generic" options per kernel (yes, crappy to do with a ton of kernels. Probably start with mainline and work backward) I haven't looked at nand-sata-install in terms of how it's written, however some of @tkaiser's feedback suggests it's a tool that has experienced significant "scope creep". Would it be beneficial to instead make a script per board and make it part of the bsp? Are there other tools where this would be advisable?

For our images, we use a single partition, so things could get interesting in that respect. I'm also not sure how the partitioning of the eMMC works, it actually appears on my board as 3 devices.

Well, I didn't copy the image to the root directory of the card, I just did it from the host PC. As long as you wrote it to the device and not to a partition (so /dev/sd(x) and not /dev/sd(x)1 ) that should be it, I followed it moments before posting it the other night.

In the future please read the forum you are posting in, we have an excellent search feature.

Hmmmm, I will test this tonight, I have been running exclusively on wifi (need a larger switch), and have not ha any issues dropping the network. I'll try to exercise it more fully.