TonyMac32

What version RockPro do you have? I think it is 2.0 that has PCI hardware bugs and there is a conflict between wireless and pci somehow. The v2.1 addresses some of the issues. Sent from my Pixel using Tapatalk

I'd agree with that limited scope, yes. The major downside is the extreme lack of I/O. It has just enough to fill the "high-speed" interfaces on the Pi header, and I had to add a GPIO expander to make sure I had everything accounted for. Yes, I'd seen/heard some rumors floating around, should be interesting.

Copy-Paste of the reference design. Very nice At the moment I'm playing with ESP32, looking in the direction of the ATSAMD51 (it has a lot of high-end interfaces but is still a micro) The ESP32 has existing software support going for it, the Atmega not as much, other than circuitpython and an Arduino core. As this is a hobby for me, and because I like the idea anyway, I'm planning on licensing everything under the CERN OHL, as long as I can at least recoup the dev costs I can keep making new things. This is as much me improving my technical knowledge as anything. (QFN24 soldered on a hot plate in my basement = new territory)

I think @martinayotte is the man for that job, I don't have as much experience with the fixup scripts as he. Now, it may be worthwhile to simply make a custom overly for your purposes.

Yes.

This gets filed very clearly under the "RK3399 is not mature enough at Armbian (and truthfully at U-boot) to click the "supported" button" problem. depending on who else wants to dedicate time to this, poor @martinayotte has been beating his head off a wall trying to get a bootloader unified for all the RK3399 boards, I've been slacking. If we can build the whole mess in u-boot and forget the Rockchip blobs I think we're better off. This is possible with RK3399, but I haven't gotten it to work. That is step one. Step 2, we must decide who's vendor kernel we are going to use. FA? Ayufan? Radxa? Firefly? None and thank them all for the effort? (See Tinker 4.4 kernel, it is Rockchip's with some tweaks, simply because board vendors don't care about any other board and so do lots of hacking and ugly quick-fix patching that makes code: 1) impossible to maintain 2) incompatible with other hardware 3) potentially insecure, depending on how bad it is (can't patch in kernel updates, for example) Step 3, Can we please use a clean mainline and maintain the patches ourselves? This would be an amazing place for the vendors to step in and help.

This is default Ubuntu behavior, a few Google searches recommend either creating a xrandr script or a config adjustment to the x server. U-boot no doubt has no modes for the native res, so goes to the next one down the line, 1920x1080. Wait a second. I turned off video output on u-boot. Can you verify you're booting the image you think you are?

What you have here is simply a crappy HDMI controller. I can't help you fix that, realistically. The reason for this mess is that the EDID is garbage. My 7" 800x480 identifies as the same. I do not have this issue with any of my displays (haven't checked 7"), 100% of which use 60 hz. Was this with a fresh install, or was it after some toying with modelines? The only script I have added involves making the hot plug behavior work. EDID lists the modes in order, native is, I believe, first. U-boot driver operates same as kernel, it is trying to set the screen at 1024x600. I will review this using my 7" lower res clone of yours (same controller/driver, etc).

Yeah, if you look at the RockPi kernel and config you will find a combo of Rockchip BSP and Asus Tinker board (I know because I found my specific adjustments to the device tree for the DSI/touch hardware, as well as some other small workarounds. More or less, while "it works", it is not something we would sign up to maintain directly, we would much rather get it right.

I merged this with the existing Tinker HDMI topic. Please keep the discussion in the thread you began it in. Have you downloaded an image in the last day? We just rebuilt the 4.4 kernel after I did some cleaning and re-enabled the rest of the hdmi patch that got disabled during some Rockchip shenanigans.

Hello Сайдо, I'd have to have a bit more information that that, however, if the PC cannot recognize it, then perhaps loading an SD card with linux can allow you to boot the SD and flash Linux to the eMMC.

I have an original Duo for breadboard shenanigans, I just couldn't budget another one since I don't really "need" it Sent from my Pixel using Tapatalk

Release WIP and CSC images from their own page with very specific limitations, including, but not limited to: no kernel or u-boot updates, ideally with the kernel and u-boot package names modified with -unsupported- Explain these are demo snapshot images, potentially even package a different wallpaper that has -unofficial- or something similar watermarked across it. Maybe even use the default WM theme.

RK3399 support is a total and utter mess. When we finally fix it, it will break the upgrade path on very nearly every board, since our current patching/boot situation is impossibly convoluted. Given the OP is not alone, and I completely understand his frustration, just imagine when that happens. Well, I did say "opinion". I would guess it takes more than my automotive-engineering-minded release conservatism to shut down or change the direction of the entire project. I will open a new thread on this topic, I may have a compromise in mind.

To be fair I am of the opinion we should not have any downloadable images for WIP targets. Sent from my Pixel using Tapatalk

Honestly it should boot a Duo image, wifi is the only issue, and making a proper device tree would fix that. I don't have one, so I can't get into it.

I cleaned and re-enabled the full HDMI patch on 4.4, @Igor it could be rebuilt.

As someone with *looks around at piles of SBC's* ... well ok, a problem, I like the idea with distcc. A little sad my XU4's can't join the party though, especially since you can get clusters with that SoC

Well, look at Amlogic, every single flavor of every SoC family has a different proprietary blob and different offsets for where it goes, it's a mess.

I think this could also be handled in stages, patches first. One of the things I see when we get a "variety show" going in a family is that the u-boot and family tweaking scripts go absolutely off the rails as far as complexity is concerned.

A thought occurred to me while watching my machine sync a bunch of repos while running the Armbian build script, and I couldn't help wondering: Could we put the board support patches into their own repo separate from the build scripts themselves? More specifically: board support for "Boards of Interest" to the Armbian maintainers would be in whatever "official" repos we dedicate, I recommend separating per board family or SoC board support for CSC goes into, predictably, a CSC repo board support for EOL boards can be spun off into their own repo TV boxes go into a TV box repo Advantages: Supporting every pet project wont result in build system bloat as it does today. Users of the script can maintain a csc board support repo with the required structure without hacking on the build script itself, making adding such a board to the "supported" repo much easier, if even necessary. While I don't "tiptoe through the tulips" with CSC boards, I do go to some effort not to break them with changes. Those boards won't be interacting with the others anymore, they'll have their own space. Cons: Perceived fragmentation of support. In reality this is a good way to disengage the build script from pet projects and focus on the boards we as a team care about. Some work to implement (although I think the biggest part can be laced into the menu where you choose the board (CSC/WIP vs supported) @lanefu, @Igor, Could we add an "RFC" tag? would be useful, and consistent with linux terminology.

Right, it doesn't do a bad job, but the XU4/RK3288/RK3399 have a lot more brute force available. Yep, I've tested it to at least boot to desktop. ;-).

I have a Samsung installed on mine, works well.

Kernel's are shared, so that shouldn't be it. I can look into his tonight or tomorrow

The Renegade is RK3328 like the Rock64, I have one on my desk. It has DDR4, however there have been the same frustrations concerning the RK3328 support in general from Rockchip. I know Armbian has put a few bugfixes out there, Ayufan has been doing double time on it, but without some vendor assistance there is only so much you can do. It is a very nice board, but I don't know that a move from the Potato to it would show you any benefit (same cores, same clock speed, better/more ram.)