gounthar

Thanks Igor, that would be enough, I guess.

Sorry if I hijack the thread, I hesitated with creating another one. I am still struggling with the OrangePi RK3399 regarding the h.264 encoding of the HDMI-IN and the camera. For the time being, I use a hardware h.264 encoder (TBS2605), but still have the project to use ARM SoCs running Armbian. I've seen other threads on other SoCs able to do hardware encoding, so I was wondering if we could make a table with all the information regarding h.264 encoding and transcoding on various SoCs and SBCs more or less handled by Armbian. h.264 encoding boards Name h.264 decoding h.264 encoding h.264 transcode Tests done on Armbian OrangePi RK3399 Y N N N (OrangePi Debian) What do you think of my proposal? Thanks.

I think that's the same SoC that the one in the Odroid XU4... which does not mean that would be easy to port it to your phone...

I received mines. Let me know what I can do for Armbian with this card.

Received that tonight. I still have to figure out what this board is capable of...

Thanks for these commands. They helped me getting my board out of a strange mode where it only displayed hw 0 0 0 0 0 0 0 0 0 0 and powerOn "someNumbers". Before that, I could not get into MASKROM mode anymore, nor in LOADER mode... It appeared kind of bricked to me. By the way, I read there that one could get into MASKROM mode from software by zeroing part of the boot partition. That's what got me into that "almost bricked" mode. If anyone has the correct sequence of commands that could do it, I will use it from now on.

It looks like I'm going to get one!

http://www.tuxmachines.org/node/125008 https://www.cnx-software.com/2019/06/19/rock-pi-s-tiny-sbc-rockchip-rk3308-processor/

Same here. Too bad we did not get any tracking number...

With the right image, I managed to do the HDMI-IN thingie on this board.

<rant-on> Why in the hell do we have to use that stupid shortening trick to get a Linux image written on the eMMC? Android images can be written under Windows by just using the recovery button (LOADER mode), why can't we do the same for Linux images (MASKROM)? As I wrote quite a few images on this board, the pads worn out, we soldered a pin to make it easier and more durable, which worked for a while... It failed after some time, the testing pad just quit and I am now stuck with a useless board... until a colleague makes another better solder. I know, this was bound to happen, a recipe for catastrophy, but, come on, two small testing pads! I could have gone Armbian the whole way, and avoid that, but I did not know what I would loose with switching u-boot, as I need HDMI-IN, sound in, CSI camera and network. I asked OrangePi if they could make another version with a switch or a jumper, and they answered they could modify if I order 2.000 boards, which I won't (and can't). </rant-on>

Well, the soldering attempt did not go that well, more to follow... I received the SATA cable, and the disk is now seen. I'm currently creating a NTFS partition.

Yes, you're right, thanks for clarifying. Today, we'll try to solder something to the pads so that it gets easier for me to go into maskrom mode.

As I will be using an SSD, I found this connector that will only give 5V. And I still have to try that, I really have to figure out this Msata/pcie/m2 thingie...

I see, thanks. I already have a parent-size Molex Sata power connector, I "just" have to get two tiny weeny Molex connectors, and a little bit of solder I guess. I received today my test heatsink, let's hope it doesn't short anything...