TonyMac32

@Tido remember the heat sink I tested was 20 mm x 20 mm, so it simply didn't have sufficient surface area to be useful. In the case of this aluminum plate, it has both a large thermal mass and a large surface area when compared to the SoC alone. Also, as compared to a lot of heat sinks, the notches run longways, providing the thickest cross section to move heat from the SoC. (The other Libre computers do it the opposing way, reducing effectiveness somewhat, although I agree that at 5-10 watts it's not critical) For the fin orientation, remember on pi-factor boards there is no air path through the header if a hat is plugged in. The RK3288 is ok, the included heat sink is not. With a 25x50mm heat sink with fins running longways it is a much cooler operator. The XU4 though, even liquid cooled it gets hot.

A while back @botfap gifted us an HDMI hotplug rule for the Tinker board, which happens to be hardware agnostic as far as I can tell, I've put it on the Odroid XU4, for instance: if [[ $BRANCH != default ]]; then mkdir -p $destination/etc/udev/rules.d mkdir -p $destination/usr/local/bin cp $SRC/packages/bsp/rockchip/hdmi.rules $destination/etc/udev/rules.d install -m 755 $SRC/packages/bsp/rockchip/hdmi-hotplug $destination/usr/local/bin fi Should this be rolled out across all mainline kernels, I hear a lot about unplugging and re-plugging monitors being a concern for some users? I don't want to pre-emptively stick it in something like the sunxi files because I could wreck the entire system if something isn't perfect, I would assume some board somewhere would need an adjustment, because reasons.

...So he can miss another planet?

@zador.blood.stained is realizing @tkaiser sent him a suspect unit for the first time... I haven't even had any mechanical failures on SD cards yet, a lot of people complained of the Tinker Board ones coming off entirely, but with a few hundred cycles on mine I think they must have been being too rough.

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

I think in real terms it would be negligible. Aluminum isn't like steel where the processing method radically changes the grain structure. From an aesthetic point of view milled is always "nicer"

To be fair that is effectively the same thing, but yes, that should do nicely. Will the production units be extruded or will they also be machined as pictured here? It would be nice if more of these SBC's came with proper enclosures, <speculation> I suspect if this much effort is being put into that you hope to keep this form factor for a while? </speculation>

I just checked out the first one, I get the failed signature and download on every run as well. New Bionic install from yesterday (my Xenial wouldn't upgrade for reasons unknown)

I found the same on Alwwiner H5-based board with Bionic: [FAILED] Failed to start Armbian ZRAM config. See 'systemctl status armbian-zram-config.service' for details. That results in a 2 minute boot delay. It seems to succeed in the end though, or eventually: tony@tritium:~$ sudo systemctl status armbian-zram-config.service ● armbian-zram-config.service - Armbian ZRAM config Loaded: loaded (/lib/systemd/system/armbian-zram-config.service; enabled; ven Active: active (exited) since Sun 2018-06-24 18:53:02 UTC; 6min ago Process: 576 ExecStart=/usr/lib/armbian/armbian-zram-config start (code=exited Main PID: 576 (code=exited, status=0/SUCCESS) Jun 24 18:53:02 tritium armbian-zram-config[576]: no label, UUID=d4c99662-9d44-4 Jun 24 18:53:02 tritium armbian-zram-config[576]: Setting up swapspace version 1 Jun 24 18:53:02 tritium armbian-zram-config[576]: no label, UUID=5b252a9a-1cdf-4 Jun 24 18:53:02 tritium armbian-zram-config[576]: mke2fs 1.44.1 (24-Mar-2018) Jun 24 18:53:02 tritium armbian-zram-config[576]: [74B blob data] Jun 24 18:53:02 tritium armbian-zram-config[576]: Creating filesystem with 12800 Jun 24 18:53:02 tritium armbian-zram-config[576]: [41B blob data] Jun 24 18:53:02 tritium armbian-zram-config[576]: [38B blob data] Jun 24 18:53:02 tritium armbian-zram-config[576]: [75B blob data] Jun 24 18:53:02 tritium systemd[1]: Started Armbian ZRAM config. http://ix.io/1eFg

Right, I've been poking around for a "usable" controller for a Type C receptacle, my BGA fab abilities are non-existent so far so I'm having no luck.

Well, thanks to the current state of the Rockchip kernel I need to check all of my patches anyway, so it's not a huge obstacle. ;-)

@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).

Just for some levity since this is the "M" series of nanoPi's, the next one from this one has to be impossibly powerful and/or artificially intelligent: https://www.imdb.com/title/tt0708481/ ... Ideally it won't commandeer a starship and kill a ton of people though...

Well, there are some options here that "SoC-on-top" designs don't allow for, such as mounting in an aluminum housing with the SoC dissipating into the enclosure. I would take a guess a heatsink similar to the NanoPi Neo's in concept, which is also Soc-on-bottom, would be available. I agree with you in that some users will inevitably stuff one of these into some plastic Pi case and wonder why it doesn't work well, which won't be too much fun... I also sincerely hope that is a Type-C USB poking out up there, so the 15 watts becomes a bit more manageable. (it does look like one)

I have a nanopi Neo Air sitting on top of a same-size mobo heatsink. I just don't have as many old mobos as I have SBC's, and rarely could I fit those into a case.

Well the trouble here is it appears these processors never actually attain the clock speed they are marketed as having. So let's say I bring a 1.5 GHz SoC to market and say it can run 2 GHz. Oh wait, that's not a random example, that's actually what happened with the S905. Were the S905 just a poor performer at 2.0 GHz it would be a very different discussion, it would sound more like the talk around the Broadcom whatever-RPi-stuffed-into-the-Pi3. Now, for whatever reason the S905 images I have built seem to operate (at least mostly) at the frequency they are commanded to run. The S905X images aren't even trying, it's completely transparent that the SoC is being throttled or running at rates with no knowable rhyme or reason. Thank you for the input about junction temperatures and longevity, it will be good info for the general public, I believe most of the team would be well familiar with T_J vs the package temp, a good datasheet will also give you the necessary information to figure out (within reason) what the disparity is. I have the 3288 throttling earlier than the vendor requires due to that, especially considering the small heatsink on the Tinker, and lack of heatsink on the MiQi (at least mine as received)

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

Well, it doesn't necessarily have to be a change log, simply keeping the kernel documentation and the kconfig notes current and accurate would be a huge help, like I said sometimes the only way to figure out a kconfig issue is to dig into the commit history for the feature that is changing, and even then sometimes it is simply luck (building Mali as a module seems to be mandatory, at least at my last check. This was not the case before and it still allowed other options ). As far as other vendors go, I believe Rockchip has the most open development as far as that goes, others keep it more secretive and release snapshots. For Amlogic the BSP / buildroot is released periodically with a report detailing the results of a group of tests they perform on the kernel like reboot cycling, drivers, etc, that's the only one I can directly comment on.

Cool. I had similar results with mine, but I used thermal paste, must have had a closer to "nominal" casting. The entire aluminum brick gets warm when running, which is a good sign (well, not so much for the RPi efficiency, but nice for the fact it's moving heat)

I don't think that will work yet, the boot scripts are still what I had done to "make it work" with the old bootloader, so it's not ready. Thank you for the update!

Thank you for the reply. My only real issue so far has been the large changes with no documented, it's caused a huge disruption to my use of the BSP, specifically the Mali changes. Another example was getting rkwifi drivers working, the documentation on how to configure the kernel seemed to only be available in the commit message for the adjustments. With some documentation these large changes wouldn't cause as many issues. As far as specific board support, I understand not supporting everything, this is the sort of decisions we are all familiar with. I can easily maintain a patchset as long as the underlying BSP stays stable. For hardware like the miniarm, as an example, there are some workarounds that should not be part of the BSP.

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

Good idea. I should be able to start working on this again once my vehicle repair is finished, the weather has worked against me so far.

My old patch simply eliminated it, now I'll just have to kill off that section of it.

Same for RK3288, that's why so many issues around Tinker board have popped up, woke up one morning and the kernel config no longer worked, Mali was trashed, etc.