Da Xue

You can try this u-boot and just have the OS as an EFI binary: http://share.loverpi.com/board/libre-computer-project/libre-computer-board-roc-rk3399-pc/u-boot/ There's two versions, one based on RK's u-boot and one based on upstream.

Neil finished u-boot UMS support for us. So, soon you will be able to flash the eMMC by exposing it as a mass storage device to your PC.

The two holes are for eMMC module securement. You can use double sided stickie stuff since the heat dissipation isn't that bad at 1.2GHz.

Did you turn off HDMI via the GPIO? If that's on, you get about 50-100mA more because of the video pipeline. Check the schematic on the product page of the website.

0.125A is as measured with a programmable DC power supply. This number would only apply in battery or direct DC application. If you are measuring from the wall, you have to account for the losses in that power supply you are using.

What power supply are you using? ARe your numbers from a programmable DC power supply? Normally not having HDMI connected at boot will usually cause the pipeline to turn off. You can also see the schematics here: https://drive.google.com/file/d/0B1Rq7NcD_39QYnltdGtWWEFvS0U/view?usp=sharing

Turning off HDMI will get you pretty big gains since the display output pipeline can be turned off. The lowest I've achieved using that basic tweak is to get it down to 125mA.

See https://github.com/libre-computer-project/libretech-linux/commit/9b6b181a0700b329876b7998eb75283ce0b338cc The previous USB patches that were posted to the libre-computer-project 4.14 branch were not the final ones. All of the out-of-tree patches for 4.14 can be found here: https://github.com/libre-computer-project/libretech-linux/commits/linux-4.14/libretech-cc-master

S905X and RK3328 both suffer from some issues with SD cards in UHS mode. When driving them at UHS speeds of more than 100MHz, the SoCs cannot drive enough current to bring the voltages up and down enough. You see degradation of the signal and some cards are more accommodating to this than others. S905X does not have reset lines for power cycling MicroSD cards which becomes an issue when you reboot and the board tries to go back to UHS mode from non-UHS. Samsung cards that I've tested will plain drop dead while Sandisk will not re-enter UHS mode. A board power cycle becomes necessary. The SoC was designed for SD cards to be pushed in and out and did not really consider using them as boot devices. eMMC is the way to go for these SoCs.

I am seeking an resolution to all the MicroSD card issues. This is why I don't touch BSPs. They are terrible and utterly unusable. Sorry about all the wasted time.

I can assure you that it would take more time to fake that video than it would be to do it for real. I'm not too happy with that video because the lighting all wrong. It would kind of destroy the reputation of everyone involved if we published a fake video. The campaign was launched before all the materials were ready because of scheduling deadlines with product delivery.

There's no plans for full size PCI-E cards because that is like Pandora's box in terms of customer issues. If 20V works, we could potentially design a mezzanine to drive PoE devices and act as a terminator for PoE camera system for computer vision applications.

The design is not final yet. The heatsink is sufficiently big to act as a buffer so the groves are not meant to serve as headspreading fins. They are there to reduce contact surface area should you put your hand on it and lift it when it is hot. Otherwise with higher power chips, you can burn your skin.

Native *speed*. Thanks for the catch. 5V and 12V works. Still trying to get 20V working.

That is some bad ass sh*t.

Longevity is not the only concern. At higher frequencies, signal integrity drops. The higher the clock rate, the more likely of errors due to propagation delays, leaky transistors, and threshold voltages. The difference between 0% overclock and 25% overclock may mean the difference between 30 9's to 20 9's which is statistically significant for error propagation.

The idea is to make it just slightly bigger so you can hook up an LCD with FPC cable. It doesn't interfere with the mezzanine since the entire design built to be stacked. If you were developing on the GPIO and have an LCD, you would have to have the LCD detached. For all intents and purposes, I don't think extruded and milled matters for heat dissipation at this power density. We are not doing 50W+.

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.

Still being designed but photos attached. Big enough for you? @tkaiser

The SoC side is the top side and we have a massive heatsink spanning the size of the board there. USB-C is for power delivery. 12V headers are for PoE.

These are already in the Armbian tree on GitHub so they are somewhat supported already. It is just not on the website.

This is going to end up like another ASUS Tinkerboard. Shove a 15W+ design in a form factor designed for 5W. This really takes the cake since it has the SoC on the bottom where you can't even put a heatsink.

It is probably in Amlogic's openlinux BSP.

I am referring specifically to the Khadas VIM. It uses a proprietary power sequence that is different than the Amlogic reference design (p212). That means if we sponsor work for mainline Linux support of suspend and resume of reference platforms, that code may or may not work for the VIM and it may require extra code has to be implemented specifically for their design.

It is a matter of time and money to get the standby implementation completed in mainline. Currently there are much higher priorities. Reducing the power consumption from 0.8W to 0.1W does have interesting applications. With a secondary MCU (not based on Amlogic's design), you would have to keep some out-of-tree power management code that is different from every other board in mainline. There are benefits and costs to that design decision although I don't think the MCU cost that much.