TonyMac32

Could I have the link output by armbianmonitor -u ? Need to know things like kernel /etc

Sounds like ARM development summarized into 1 statement.

@tkaiser sorry about the delay, I lost track of this with all the other stuff going on. No, I'm not getting anything on a new build. root@lepotato:~# cat /sys/class/hwmon/hwmon0/temp1_input 28000 works, but the soctemp entry in datasources does not exist. This one was built off of the master branch with the recent syncs, armhwinfo looks to have the above commit in it.

@Myy I stumbled across this today: https://openedev.amarulasolutions.com/display/ODKERN/VCODEC+on+RK3288

Verify 110 ohms here, powered on no shield.

You have to declare the console going to the HDMI in the config

Because Linux support is not mature for the H6? It's hard to release a distro for something that doesn't have proper kernel support. :-). @Vincen, The Asus Tinker Board, and MQMaker MiQi have experimental video decoder and GPU support. I'm not as familiar with the other boards to know what they can and can't do in that department.

Have not tried it so far, I guess it depends on whether a dw-hdmi driver is in there or not.

There are two types of development branches: permanent and temporary. For a permanent one yes, curating is a necessity and "naming names" is needed. For something more specific (changing kernels, adding a driver, targeting a new u-boot, etc), a branch for that change could be made, tested, reviewed, flattened and committed into master, and the branch removed. The owner of that branch is the creator of that branch.

I'm away from my computer, are we using the BayLibre patchset on C2? If not the u-boot might not function properly, I remember Neil saying we needed those patches for Le Potato to use mainline u-boot.

Hahaha no, I was excluded from "The list". Only a joke, and there has been some quite loud opposition to naming a "king of the project" or an "inner circle". Personally I think a lot of this comes down to not wanting to assume the complexity of a larger project, but the project has decided it won't wait for that complexity and is now demanding it. We're at the point where Armbian gets mentioned in kernel mailing lists about various SoC's, so our ability to address issues is becoming quite public. I only push the branches because if someone makes a stupid branch we can kill the branch, and changes won't be wound around anything else that may be useful causing a horrific mess.

:'(

I keep coming up with either a "wip" branch or a branch per SoC/big change. It seems more complex at the surface, but they are temporary branches. Easier to maintain than a fork, less confusing/scattered/mixed up than a single dev branch. Should have dev-rockchip, dev-sunxi, dev-meson64, etc. When we decide it is stable, we flatten it out and put in a PR and someone who isn't the PR requester needs to review/ack it before it can be merged. Incremental kernel patches should be applied to "master" since they should only ever break one family, and should be fairly consistent across all members. But, is off topic for this thread.

Well, that's still more or less it, with me working on Meson64 and rk3288. PR's have increased a little in recent weeks I think, and sometimes they aren't being thoroughly reviewed, but that's a situation where the only solution is to hold ourselves to having people review and acknowledge a PR before it can be merged. I think the variety of "special needs" boards is a problem, an example is the amount of time I have to spend simply keeping Tinker adjustments from breaking MiQi before rolling them out (and with that I'm not 100% successful). I can't imagine the array of "same but different" Allwinner boards, and looking at the patch directories kind of shows it easily. It's one of the reasons I was willing to suggest the Tritium boards, so far they have no special needs, other than the likely mistaken identity issues that could surface. (And honestly, with the naming conventions of OPi and BPi, they have the same issue, if for different reasons)

You could say that... As far as what I said. ;-). The bootloader on K2 with Armbian is a binary blob from a 2015 release of the bootloader, with some modifications by the SoC vendor. It does not support a lot of things that are common today. Mainline is the current release and actively maintained version of the bootloader, it doesn't have "plug and play" support for this board but it does for a nearly identical board from another company, and it supports all the interesting boot methods.

For the OP, if you can locate your kernel on the card, you can replace it with your new kernel. Make a backup of the original kernel image so you can go back if things are ugly. @chwe saveenv is a normal u-boot command, in my opinion if they manage it they're advanced enough to take responsibility for what they break. ;-) I do it all the time. I want to see if the boot menu can be implemented in the boot script, that would be key. I'm currently reading through @umiddelb's "U-571" repo (excellent naming, by the way)

Yes, the naming scheme is quite unfortunate in some cases, it's not like an RPi B vs B+, where the SoC is always the same.

On your distro I have no idea. Armbian has a txt file set up by default

I want to play with this now.

Jealous.

I'm ok with generic, most industrial and control situations require boring and generic because it's stable and easy to replace, it is the ?? that causes the issues. I haven't seen any actual technical failures baked in so far, unless you count being artistically inspired by a credit card sized computer a technical requirement.

Well, to be honest I'm not too excited by most of the boards being released short of the rk3399/H6 ones, from the standpoint of a new brand coming into an already crowded marketplace, it might be best to release a series of "minimum risk" boards first. And given that everyone has tried to put their own spin on the RPi form factor (MiQi, ? Pi, ? Pi, ? Pi, ? Pi, ? Pi, ? Pi, ? Pi, ? Pi, ? Pi), it's not unexpected that someone tried to go as conservative as possible with it, sticking to current SoC mfg recommendations and minimal peripheral sets. (I might have to register "Spaghetti Pi", seems like a good idea...) The lack of voltage scaling I agree is a negative, and thank you for the history on that, my Allwinner background isn't the strongest, I've obviously only seen the bad examples... . The website, well... Schematics are there and so far haven't had any demonstrated issues (not an exhaustive analysis), and the device trees added to the mainline kernel look complete. But yes, it needs work, looks not the best when everything is "coming soon". Cost. I agree I'd like to see them closer to the crowdsourcing values, but it's likely the crowdsourcing was a manufacutrer-cost introductory price to help get some startup capital/attention. Probably a projected market price during the campaign would have helped (I haven't checked to see if it is there) To my (intended) point, the boards are basically breakouts for the SoC only, so while there aren't hugely compelling reasons from a "wow that is interesting" standpoint, there is almost no support requirements for this board series. I think of all the "uninformed RPi convert" boards it should cause the least trouble. Stick with mainline only on it and, if anything really bad surfaces, we end support.

Certainly. Or while we're sorting development branch out, I could just split this into a separate branch for the time being.

It was a passing thing I had no use for at the time, but https://github.com/u-boot/u-boot/blob/master/doc/README.bootmenu

Question concerning U-boot and our bootscripts. The 2015 and mainline kernel approached loading in a significantly different way, and I'm not certain how I can move to mainline u-boot without breaking existing installs when they apt upgrade. Thoughts on this are welcome