TonyMac32

Sarcasm is not the same as malice, sarcasm can be used humourously or in an ironic context. Delusional, on the other hand, is quite negative and I do not know what "inter-recipe" is. It is difficult at times to have so many communicating in a 2nd language, not everyone's particular "flavor" is the same. I get caught in conversations between Japan, Hungary, France, Germany and Mexico regularly, for instance. I will review this Ethernet issue you report, can you verify the kernel you are using? Also, the driver is not a mistake, it is the proper driver. I experienced a brief self-correcting interruption transferring a large file, but so far have not experienced the connection going down. I will try to aggravate the failure mode.

Anyone who typically updates on nightly kernels I would recommend freezing and not updating until we clear up some issues gifted us by some large amount of upstream changes that broke well, pretty much everything. I will update this thread as things get brought back to life. June 7th 2018: I've made a branch (rockchip-default) to work out the kinks. So far I have the board booting and Mali working again (with an initial error on load) , however there is no HDMI terminal, so initial boots would require a uart or SSH hdmi terminal is back thank you to Ntemis on github, I'd missed part of the conversation (I only have cell phone while at work) July 19th 2019: an issue with kernel 4.4 and spidev came up, no one is apparently using it, in any case Pi Supply found it while updating Tinker Board support. Fix committed.

It is new to us in the last few months, and the Linux community in general, so there is some work to be done. But I agree, it should be very nice

Try the one in the build system "rockchip-default" branch, I booted that before pulling some patch cleanups in from chwe , I will be working from there tonight. I think this all comes down to loosely defined kernel configs, little hidden gems like that wifi one where it only appears in the commit comments.

Can I have a pet robot? I'll name it David Tinkerhoff, it will be a big hit in Germany. but yes, unfortunately the current status of the tinker vendor kernel is quite bad. Once this all clears up I may wind up cloning the kernel to make sure we have a stable point to work from. For now there is no possibility to worry on this topic.

I think @constantius forgot to add a comma: I assume with my edits this is the sarcasm that was intended.

Now that is an error I have never seen. I built multiple images last night, but they were all xenial, not that that should impact it... @Igor your thoughts? The board config specifies meson64 like it always has...

We have a patch for that. And yes, that caused me some frustration. I've been tracking the progress upstream, I just wanted to see if I could do it, especially the fip magick. It is so far just a clone of the C2 code using the generic gxb blobs and a K2 dts, I'm planning on moving to the newer u-boot soon, my first experiments were before it was final so I stuck with .03 It's in patch form in the build system: https://github.com/armbian/build/tree/master/patch/u-boot/u-boot-meson64 And blobbing it all into u-boot.bin: https://github.com/armbian/build/blob/master/config/sources/meson64.conf You'll see the subsection, it's huge. The "odroidc2-blobs" directory is so named because it was the first board, each board has a folder inside there with appropriate blobs.

I really identify with that guy's frustration, I took one of his rants and substituted sensor words for software words and no one could tell I hadn't written it. I'm really extremely pleasant here (comes from being the least knowledgeable among the devs, I at least try to shut up and learn) Skype was never valuable in the US, now they rebranded Lync as Skype, which in my opinion made it crappier (there is nothing professional about Skype) I can't remember ever having a Nokia... Maybe one of my early button phones was one, the first I bought myself was a Sanyo Katana, an exceptionally solidly made device (better built than the phone it was a blatant ripoff of)

I have discovered that the K2 (S905) appears to not "make up numbers" as the S905X boards do, I'm playing with sysbench. I came to this because it is running significantly hotter than Le Potato, which is S905X. I'm going to switch it to conservative, for the boards with firmwares that "make it up" on the front end this will most likely do nothing, but at least on K2 it will cool it down.

Setting max frequencies at 1 GHz I also get the right answer: 9.258 seconds

@tkaiser ran this on the NanoPi K2 since I got it running again today, since it is A) running hotter than Le Potato and B ) has a different set of firmwares despite being from the same amlogic buildroot (gxb as opposed to gxl). It advertises 1536 instead of 1512 as it's top CPU speed (s905 like the C2) Run 1: Maximum prime number checked in CPU test: 20000 Test execution summary: total time: 6.0123s total number of events: 10000 total time taken by event execution: 24.0414 per-request statistics: min: 2.38ms avg: 2.40ms max: 14.40ms approx. 95 percentile: 2.47ms Threads fairness: events (avg/stddev): 2500.0000/28.91 execution time (avg/stddev): 6.0103/0.00 Run 2: Maximum prime number checked in CPU test: 20000 Test execution summary: total time: 6.0135s total number of events: 10000 total time taken by event execution: 24.0320 per-request statistics: min: 2.38ms avg: 2.40ms max: 14.47ms approx. 95 percentile: 2.47ms Threads fairness: events (avg/stddev): 2500.0000/31.99 execution time (avg/stddev): 6.0080/0.01 Run 3: Maximum prime number checked in CPU test: 20000 Test execution summary: total time: 6.0238s total number of events: 10000 total time taken by event execution: 24.0759 per-request statistics: min: 2.38ms avg: 2.41ms max: 14.43ms approx. 95 percentile: 2.47ms Threads fairness: events (avg/stddev): 2500.0000/30.04 execution time (avg/stddev): 6.0190/0.01 As far as running hotter, it is sitting at 50 C at idle, Le potato will set around 38-40. Notice execution time is significantly faster than Le Potato with S905X. Something I noticed on both is that "ondemand" simply keeps the CPU at maximum frequency at all times. This true of both boards I have, I'm going to change it to conservative since that's probably what's actually happening inside the S905X anyway. According to @willmore's data: That is 1536 MHz as reported. Now mind you I am using the blobs from the same buildroot in both of these images, no special vendor stuff anywhere. So why did Amlogic decide to screw up the GXL so bad? Or did they "fix" the entire GXB platform because of the uproar over the C2? [edit] System reported the 1.7 and 2.0 GHz operating points, so I tried the 1.7 just for kicks, no change in performance. ;-)

I'll check on that. I have the hotplug service on Rockchip (not hardware dependent), and added it to the XU4, should we just move it to bsp/common/lib and add it to the boards that need it? the only other thing in there is 71-axp-power-button.rules at the moment. @constantius If you can build it yourself I've just pushed an update on the K2 to go to u-boot 2018.03, which has a ton of improvements to the handling of memory/device drivers. I need to do some more tests on K2, but since it was broken before I felt the limited testing I've done so far has been sufficient.

Had a little time to test this today, as expected, it's junk. Being copper it moves heat quickly, having no real fins or the like it simply has nowhere to move it to. It can handle "smoothing out" the heavy thermal loads, but it simply can't move enough heat.

I would wait on images until we get the bootscripts "up to code" with what is expected. I'll need some help there. Then we'll have armbianEnv.txt and such. I made sure the existing boot scripts worked before putting in the PR, so nightly will be ok.

Well, without completely abandoning the entire software base it currently relies on, that's not possible. TBH technology wise, RPi hasn't been "the one to beat" in several years, there's no reason to suspect it will be any time soon. It's strength comes from the commonality and community it has.

Excellent. Kernel config issues. I'm on the right track with the Mali I think, filtering through feedback and I now get a desktop coming up making mali-for-android a module. Apparently when Rockchip says "allow compile as module" they mean "force compile as module" With the mali as module:

Yes, TinkerBoard is likewise all messed up wrt Mali drivers with latest Rockchip updates. Enable the mali_pwrsoft option.

Using u-boot 2018.03. ;-) . The problem was how to get the binary blobs into the right order, I hadn't looked closely enough. Now that I have that, I need to properly power-up the K2. This is to move forward from the 2015.01 blob we use right now. [edit] The issue was the odd-ball fip_create in the repo we keep the blobs. The hardkernel fip_create tool is not compatible with any newer blobs. Used the proper tool and booted it right up with u-boot 2018.03. @Igor I will push these final adjustments and merge the code if no one has any objections. There has been a PR open if others wanted to test with Le Potato, so far I've had no concerns with it.

Alright, highlighters and it is. There looks like about 3 pages of code linked to this, and it's only 75% variable names, so it shouldn't be that bad. ...or I could just add V=1 to the mk script... [update] Image is successfully made, it freezes on loading bl33, so I have some board init work to do, I took a gamble that it was nearly identical to the Odroid-C2 and lost. The u-boot.bin.sd.bin appears to be the proper format, data where it goes (hex editor and comparison with the actual Amlogic build environment results) If something I'm not smart enough to see is in the text below, let me know. no sdio debug board detected TE: 286127 BL2 Built : 11:58:33, May 27 2017. gxb gc3c9a84 - xiaobo.gu@droid05 set vcck to 1100 mv set vddee to 1000 mv Board ID = 8 CPU clk: 1536MHz DDR chl: Rank0+1 same @ 912MHz DDR0: 2048MB-2T-13 DataBus test pass! AddrBus test pass! Load fip header from SD, src: 0x0000c200, des: 0x01400000, size: 0x00004000 Load bl30 from SD, src: 0x00010200, des: 0x01000000, size: 0x0000d460 Sending bl30......................................................OK. Run bl30... Load bl31 from SD, src: 0x00020200, des: 0x051000[00, size: 0x00016380 Image: gxb_v1.1.3221-2cfba69 2017-05-27 16:04:23 qiufang.dai@droid07] OPS=0x13 efuse_setup() 573: HDCP=0x0c REG32(SEC_AO_SEC_SD_CFG9)=0x00000007 f8 a2 41 21 93 17 68 97 41 23 b a7 [0.385967 Inits done] secure task start! high task start! low task start! Load bl33 from SD, src: 0x00038200, des: 0x01000000, size: 0x0006ace0

@Tido because of this issue with the IR being linked to the closed-source blobs (wakeup/suspend stuff), Khadas used a separate micro controller to handle those functions. It doesn't look good.

You could say that... To gain 120 degrees C in let's say 10 ms with Si's Cp = 711.75 J(kg-K) assuming say 1g of silicon and 10 ms (really gross estimation, but I'm having some fun here) it should take something to the tune of 8500 watts of power, unless I forgot to carry a decimal somewhere... I have some pretty hefty equipment at work and I can't pull that off without a much broader "thermal event" (and probably getting fired).

My addiction got the best of me and I picked up a RockPro 64 as well. ;-) OK, back to the cellar...

Someone in the devs would need the hardware. As these RK3399 boards are a bit expensive to buy without need, I'm not sure that will happen. Some ideas though, should you put together a solid PR against the Armbian build system: Kernel: Mali Midgard, right? current rockchip is r18, but there are some config woes. Rockchip x: yes, there are some issues, @JMCC is better understanding from his work on RK3288, the other "fast" Rockchip processor. He has the 3288 set up for mali and mpp, once we get the newest Rockchip drop stabilized again... Firmware: Can be pushed to the appropriate folder in the build system. Rockchip gstreamer: See my earlier statement, gstreamer is not the only option. :-) Bluetooth: AP6356S, is this correct? You may want to completely ignore the rockchip bluetooth rfkill system and use something like (obviously different based on the chip/gpio's/HCIattach used):https://github.com/armbian/build/commit/ac8d0d86687007c894caf18b0ba85d99c38eb8b1#diff-720eab911ea238eb515a7dd36d99234e The service calls the script on boot and enables it, then, if called again, resets the BT and re-initializes it. It also required defining the UART fully in the DTS, as by default, at least on Tinker it didn't have the CTS and RTS assigned under the UART. Sound: can be adjusted during image build time in the script (Tinker does this, as do some others IIRC) For a merge, you would need to make the needed changes and put in a PR, and some more discussion would have to go on about the potential risks/etc of supporting it.

Current list of things to fix before I'm looking at Tinker cameras: -Mali -Touchscreen -device tree overlays -Tinker S hardware monitoring (voltage and headphone plug, eMMC availability with the jumper in recovery mode) -Meson64 stuff for other boards that I also help maintain. -something that will certainly require attention before now and then -cameras that only work with 1 board.