TonyMac32

Is this still present? This looks like a temporally (upstream) network related bug.
 
Yes. Fixed. Now it is also clear why u-boot was from Rock64 ... I haven't notice error while compiling ... and since u-boot was already present (not cleaned properly) ... it didn't break the compilation. I'll remake it and put to the server.

Yes exactly, just applied the patch and the kernel driver is back in the game

https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git/commit/?h=v4.14.52&id=16d7ceb04b554207aa68dd27c1bc11f8933813fd

Ah, EOVERFLOW... You might need that kind of patch applied to the Mali drivers : https://github.com/Miouyouyou/RockMyy/blob/master/patches/Midgard/r19p0-01rel0/0009-GPU-ARM-Midgard-Adapt-to-the-new-mmap-call-checks.patch
 
They might have imported Linus Torvalds patch to mmap into the 4.14 series.

I own the board, give me some time to get it set up

Sent from my Pixel using Tapatalk

I would prefer 'speaking' names so renegade is IMO better than roc-???-cc. Soon there will be a "Renegade Elite" available based on RK3399... and renegade-rk3328 and renegade-rk3399 look almost the same. So maybe calling this now just renegade and the RK3399 board then renegade-elite?

I've picked up a couple USB meters: https://www.amazon.com/gp/product/B01D9Y6ZFW/
 
And a chassis supply: https://www.amazon.com/gp/product/B018TDT20I/
 
I'll verify the meters with a Fluke I have access to (I'm a simple son of a farmer, I can't afford toys that nice) and will be setting up a multi-board bench feed.  There is actually good reason for my choice of power supply:
I got tired of having 6+ wall adapters lying about and no wall sockets left.  I have everything I need to make a proper power distribution block with the chassis supply. The USB powerstrips do not offer the flexibility of the MEANWELL, it can be adjusted from 4.5 to 5.5 Volts and has some acceptable regulation It is cheap. If I decide using it is a waste of time I can use it a permanent solution elsewhere. I plan on doing voltage dropout testing and power monitoring.  And having less of a mess, maybe...

Hi guys,
some months ago I implemented an Odroid C2 as readout controller for a scientific instrument.
Lot of people were kind and helped me with some problems with Armbian, especially eMMC and PWM.
 
Today, finally, we managed to have our instrument (two strings with several Odroid C2 and other stuff) deployed.
It is sitting now at 2628m depth in the Pacific Ocean, and will go operational the next days.
 
Here we are... I think I can announce the deepest Odroid so far (cry loud if I'm wrong :) )
In the picture you just can see the Titanium housing with two glass covers attached to the string.
 
Again, thanks for the fish :)
 
Michael

I haven't had a board fail yet.  Maybe I'm too nice to them...  

That basic design will be used on all 5W-20W power envelop solutions including the S905D2/X2 and S922. It is CNC milled but designed with mass production in mind. 

I was recently looking at TI's catalogue and came across the TPS65987D
It a QFN so can be reflowed without having to worry of bga shorts. :-)

@JMCC Nice review, I still need to get my system running... :'(  
 
@tkaiser, there is very little "special" with the rk3288 boards we support, the Tinker patches have been carefully (well, as carefully as I can manage) tailored to not harm the operation of other boards (the Tinker Reboot is a nasty one, it's hackish code that I wrapped with a device tree check conditional execution).  The MiQi is basically just a Rockchip development board, nothing strange to get in the way. 
 
I would support a common BSP kernel for all the devices, for Mainline though I would recommend using straight official mainline and grab patches for the important things from the "almost mainline" or "will wind up in mainline" repos (easy for me to say when the RK3288 is almost perfectly supported at this point).
 
 

Wow, even cnxsoft points out that BPi doesn't even know the specs to the thing they're selling.  

I'm Kever Yang from Rockchip BSP team, and I'm in charge of open source for Rockchip SoCs, you should able to see my patches to upstream U-Boot and kernel. Thanks very much to @tkaiser for share this thread to me, and I hope I can do some explanation here so that help developers understand what we are doing.
 
The github(https://github.com/rockchip-linux/) is owned by Rockchip,  and repos on github consider to be a 'Linux SDK' of some of Rockchip SoCs(mainly for RK3328, RK3288, RK3399 now), we have a wiki to provide basic document for it(http://opensource.rock-chips.com/), the github is now maintained by one of our product team. We hope this github can be a good reference to developers who interested in Rockchip platform.
 
I have to declare that Rockchip never try to stop community developers to report issue to Rockchip by github or by mail, but it's not correct to close issues without any comments, I'm sorry about what we have done and I promise it would never happen again. For some issues, we may not able to fix it, but people should get a saying if we have to close it. Rockchip always open to community, and, yes, we hope to get advice about github maintain.
 
Here is the information about Rockchip source code:
- Rockchip have only one common BSP maintained by BSP team, including U-Boot, kernel, rkbin(ddr, miniloader, trust), this is used in all Rockchip products and for many SoCs, so it including 4.4 base/LTS patches, upstream backport for some modules, vendor/rockchip solution for some modules because the requirement for production;
- Rockchip product team will test for product SDK release, but usually only for one SoC per SDK, and it will fix at that point before next version SDK. 
- Rockchip kernel is now 4.4, and will update to next LTS;    
  We try to use upstream source code as much as possible for all the modules, you can find this out by compare to our last version kernel 3.10, but still way to go.
- Rockchip kernel is used for Android and Linux OS;
- Github source code is a special 'Linux SDK', not like other 'fixed after release for one SoC' SDK, it keeps update and used for more than one SoCs, you can consider it to be a mirror of Rockchip internal BSP
     * that's why we not able to merge the pull request, we have to review all the source code internally;
     * the github release branch is  not maintained directly by BSP team, so it may not have maintained good enough now, I will sync with the maintainer, we will have better test, and better release flow;
- Rockchip don't have official community version BSP which only have everything from upstream, and won't going to have one in near future;
- Issue report(feature defeat, performance and etc) are always welcome, we want provide a better common kernel.
    We will fix issues really need to fix, people don't want to get a kernel always have the same issue.
- We focus on evb first for new SoCs, and some popular board will add later; this may be one of the conflict with the what community wants.
 
    About the common kernel for community, here is my suggestion:
- Community can chose one kernel version fork from Rockchip as common kernel, now the kernel4.4 already has good support for RK3288/RK3399/RK3328;
- Developing, apply patches for new board support, switch some of module to upstream driver, and so on;
- Upstream the new board support or feature support as much as you can, then rockchip kernel can support it when update to new kernel;
- If some feature/performance issue need to fix recently, community people can contact Rockchip/me, we will try to fix it if we can;
- maybe a mailing list is needed for better communication?

Please download 5.42 image, updated u-boot should solve this issue, it is a memory problem with the storage location of the firmwares

@chwe @TonyMac32
 
Well, in the end I have bought the 1054Z. And it made its debut sniffing the phone line voltages in order to ensure if is my carrier providing "voltage reversal" upon disconnect. It was not :-P
 
Tony, you might love the discussion (bottom) at https://hackaday.com/2016/10/05/choosing-a-scope-examining-bandwidth/
 
 
 
 

@TonyMac32 It's not an issue, u-boot will cycle over all mmc interfaces, numbers are unrelated, mmc0 is the first mmc interfaces, on Potato it's the SDCard.

No need. We are sticking to LTS. I don't really pay a lot of attention to what is enabled for nightly ... changed to NEXT https://github.com/armbian/build/commit/8f47d7fab97f3a97da9af671365dc5d6dca64052 

I created a NEC IR code receiver. It's really pretty simple. The IR receiver on These ARM SBCs is just a digital signal connected to a GPIO pin. I shared a demo program on GitHub here:
 
https://github.com/bitbank2/ir_receiver
 

Yes, with some patches, in the same repo. Only succeeded to boot the 4.4 legacy kernel, though.
 
Copy the device tree from FriendlyELEC's kernel, and it boots with Rockchip u-boot and kernel. Their kernel modifications are mostly for their accessories, like several LCD screens, touch screens, etc.
 
It's a rough port, especially for u-boot. Since T4 does not have upstream u-boot support, and I only spent a few minutes creating the dts file from the Linux one. (Still a lot of bugs, like USB is not functional, so you cannot load kernel from a USB device. but that's sufficient for booting linux kernel from emmc/sd)
 
As for 4.17 mainline kernel, it's still far from complete.
1. CPU-bound tasks are not pinned to the Cortex-A72 core automatically
2. HDMI not working
3. USB3/USB-C not working
 
so I did not spend time investigating on that running on T4. It may be a lot better later this year, though.

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.

There is no such config in our current build script: https://github.com/armbian/build/tree/master/config/boards
 
Exactly

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.

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.

In case not, I also enable Bionic Nightly desktop target which will become available once during the day.
https://github.com/armbian/build/blob/master/config/boards/nanopik2-s905.csc#L13