TonyMac32

Well, I missed that memo. Now to upgrade apparently...

Well, we're not a free resource for other people's projects in this specific of a context. What you're proposing would easily double the workload I put into a side project that does not pay my bills, simply so you can have something for nothing, so they say. I'm not trying to be rude, but I don't have time for every user's pet project, Once I get the latest Rockchip updates stabilized I may spend some time on getting the ISP driver working, or I may not, but that will be the limit, is to get the hardware to a functional level. Any special or new functionality is outside of the scope of what I have time, resources, and in some cases knowledge. And you think a loosely affiliated group of programmers doing this for their uses and enjoyment can?

well, I would need to spend some time playing with it, but I doubt the notch filters on those are so amazing that they don't see +/- 2 khz difference in carrier frequency, probably the reason for grabbing a 38 kHz, the other options look like 36 and 40 kHz. I would need to sit down with one and play with it for a while to be sure though.

Fair enough.

As long as we control the kernel so it doesn't get modified and break compilation at the tag.

Well, yes, that is the driver for the camera, now, how it interacts with the Rockchip ISP driver is a question, I assume our issues are purely kernel config related, but Hell if I know what the config should be, it isn't documented very well. Good question. As I haven't yet, I don't know. :-) Everyone, and seemingly no one. Take yourself as a casual example. Everyone wants it, no one wants to do it. Unfortunately, at the moment we have bigger kernel config problems after some upstream updates so the camera is not on the immediate list of things to fix.

My last try with that recipe didn't work, but I need to try it again.

A swap should be possible.

Another big batch of commits, sorting through them.

I would not think so, it didn't really make an appearance until 4.12. I have not tried to apply the RT patch to the rockchip kernel. It is highly unlikely it would work right out of the box, there's a lot of customization in there, years of patching, in fact.

Yikes. [edit] This might have something to do with the recommendation to only run 1.6 GHz, the patch over at Tinker to limit CPU frequency when GPU is in use, etc. Almost done with day job, then I can actually look at code

Does it though? I have a BT speaker I paired today to verify, I got clean audio. Did the headset give you the option of being an audio sink, or did it default to a handsfree? (I've had this issue) - The cpu governor has been known to cause audio issues on USB devices, I have moved the default to "ondemand" from "Conservative" to see if that helps, perhaps that is an issue with the BT as well? DMA is still disabled for the UARTS to my knowledge. I've put in an issue on the Rockchip repo to see if I can at least get a description of the change in regards to breaking everything. I'm still tracking in circles on the HDMI audio issue, it must be due to alsa config

I don't prefer to "call in the artillery", but I've run into a wall on making the "u-boot.bin.sd.bin" for the NanoPi K2. The U-boot part of it is honestly done with the gxb work, just making it it's own entries and such with minor tweaks where necessary, but the Amlogic FIP stuff is just... ugh. The C2 has a special "bl1" as they call it, so that method isn't correct, and reading through the make file in the amlogic u-boot is making me wish for sharp objects to poke out my eyes. If @balbes150 or @Neil Armstrong know the steps to meld the blobs and the u-boot.bin right off the top of their heads, that would be amazing and I can wrap this up. If not, I'm printing a Makefile and getting at least 4 different colored highlighters...

I have created a branch for amlogic device mainline u-boot, I have successfully booted le potato now, it took some small adjustments to support the 2015 boot script. Anyone wishing to try this use LIB_TAG="meson64-uboot" Next steps: use a proper boot script to take advantage of armbianEnv.txt and bring Le Potato to modernity. using C2 as pattern bring up mainline support for K2

Check the MAC address's, these don't have one built in so if they all have the same one it will cause conflicts. Setting it can be done in the env file if memory serves, pick one for each board. In this case Google is your friend. [edit] on Armbian that's not a proper solution yet, still switching to mainline u-boot with support for the environment files.

See https://github.com/armbian/build/pull/981/commits/7bc41c132f315e195fc3d2414f9b04cf836d145b I'll see if that gets the Android driver working as expected, and I'll reach out to Rockchip about what the recommended course of action is.

OK. @Myy I know 4.4 isn't your interest, but does this warning look familiar? I'll try compiling it with gcc 6, they were correcting stuff for gcc 7 so I went with that when it built properly, but they may not be using it it would seem (I put in an issue/got it corrected on some wireless driver warnings that gcc 7 would not allow vs gcc 6)

OK. I have an idea, but it's one that honestly a dual NIC board (Rock64 with expansion board, etc can do, and that's hook up my HDHomerun to a TVHeadend server directly, keeping their traffic off of the main network. To use both of the ones I have 3 adapters would be good. Possibly to play overseer on a small cluster of boards? Seems an academic use at best though. Still, it does seem interesting

OK, I wasn't sure if the updated u-boot packages had made it into the repo yet or not. The tinker S boot patch was in the development branch and only in the last few days made it to the main branch. It will take a day or two to roll out the new images.

I can test this later today.

Specific points are Bluetooth and sound.

I guess my question is, what is the board for, really? Also, should we expect this level of "uniqueness" from any other boards using this SoC? I don't have this board to poke at, but my goodness...

Ok, boot from SD again, apt update and upgrade and try nand-sata-install again. @Igor we need to rebuild the images for download, let me verify the current state of master is good.

Please verify the version of Armbian? I have a Tinker S running from eMMC right now, when did you download the image?

*blows dust off of JTAG adapter*