TonyMac32

It is available as nightly build through dl.armbian.com @lefedor only 4.4/4.14/4.19 kernels exist at this time, but none have proper dtoverlay support as yet. So you would have to modify the device tree yourself and recompile it, again assuming that CAN controller driver is in the kernel.

My understanding is Allwinner does not officially support the use of dynamic voltage on these processors anymore, too many boards/TV boxes were "doing it wrong" and smoking the processors, since the solution really is kind of clunky. Note that this severely limits the maximum CPU speed. (1 GHz ish?)

Honestly I don't know if we need another of a lot of things, but I can't think of anything I would have to do for this on the Armbian side that wouldn't be useful to your or any other library/user, so I don't see any harm in it. It does have the (perhaps ominous old-school Windows IE integration? ) advantage on it's side that Adafruit ships all of their devices with this micropython derivative, so it is inevitable that people moving from an adafruit micro to an orange pi will come on this forum asking questions/support "as seen on" Adafruit's site. And they've generated a lot of code for gadgets, I'm sure some of it can be useful outside the context of their specific library. I know I personally wipe out Python and go straight to C on micros, but I'm also sitting here with 20 years of programming experience. If the people I bought gadgets from had a library and I was new I'd use it. @sgjava I need to check out your JVM bindings, I never tried doing anything hardware with Java.

This falls somewhere between "how-to", "research", and "development", so I stuck it here. @adafruit is working to target CircuitPython to Armbian devices, something that will be a bit of a task. I've been playing with the code to get it working on my Tritium H3, finally did (some extra sudo-ing was needed), so I'll probably toss in a couple board definitions/help here and there if I can. it had hijacked a C2 thread (not completely, it was at least about using it on the C2), and I thought it best to continue discussion here. @chwe, @sgjava, and @Larry Bank all have various experience with various GPIO tools, their interest may vary. My current observations, doing some hacking to make it run on my board: superuser is necessary to get to the gpio I had to install wheel before blinka or setup failed spectacularly board detection is crazy (I noticed in the PR that it is planned to get worked on) I had to inject my board name into seemingly 30000000000000 files. Next up is to actually use it to read something/write something, and make a PR or two.

Honestly that's the only Pi I use for anything. It is more stable than the 3 for video in my opinion.

In general we seem to get a schematic with some pin labels, not always complete, and certainly inconsistent. (Some like FriendlyElec do an amazing job, Libre Computer provides some spreadsheets, etc) Since Armbian is as much about "making it better" as it is about "making it work", I thought a good project that a lot of people could participate in is a relatively unified GPIO reference: https://docs.google.com/spreadsheets/d/1dJq7MM1_zA5HtXywDMZ9HMKyPaNgGmkxnuz3wYuk4s8/edit?usp=sharing I don't know that a google sheet is the best system, but it serves to illustrate my idea. Provide a consistent format so there are few questions about what on earth you're looking at Try to color code for ease of grouping functions visually Document all pin functions that are practical (NAND is missing from the Tritium pins because not all of the necessary NAND pins are available for use) This will take some datasheet diving, but it should make it possible to understand the full hardware availability from the GPIO's on these boards (Tinker has a TS interface exposed, for instance, and Le Potato and C2 have SDIO)

So it's booting, but it doesn't like your display. Do you have a uart adapter so you can get to the serial console via terminal emulator? then you could provide some debug information. Another option is to boot Tinker OS and identify the monitor that way

Drivers. I don't know what the HDMI --> TFT adapter is, maybe RTD2660H? In any case, without one I'd never be able to debug it properly, throwing some kernel modules at it *might* fix it, or not. If you can get me real tech specs, such as chipsets used, etc, that makes it more likely to get a positive outcome.

I mean, I have 2 RPi 3's collecting dust. I'm not even mildly interested in trying this image... Let them sleep...

Well, in something other than all capital letters, the explanation is that the kernel does not fully support overlays just yet. Also, you neglected to tell me what kernel you are using. The 4.14 images have broken spidev right now, I haven't fixed it since I didn't notice until recently, and we have the 4.19 kernel nearly debugged, which will replace 4.14. Dev images at least support the spidev so you could use CAN in user space. Until I add the mcp2515 to the kernel module list (I can't remember if it's there), a dt overlay won't help anyway.

You've chosen a board we're actively developing and merging into the main Meson64 build family, so please let us know of any rough edges, of which I'm sure there will be a few. Sent from my Pixel using Tapatalk

@adafruit I haven't tested it yet, but the odroid C2 client images have spidev set up for both chipselects in the RPi locations. I got caught up in a lot last night and didn't get as far as I hoped, working on libre computer Tritium H3 first since it had an SD in it already (ok, lazy). [emoji38] Sent from my Pixel using Tapatalk

I am willing to put in time on the overlays/etc, my lack of knowledge is how we specifically use the bootloader scripts to apply them. I am reading through the Allwinner example, but... Sent from my Pixel using Tapatalk

Hmm, The odroid-N1 is an RK3399 board, maybe that's what's killing the gpio library. Or the header may be irrelevant, I honestly don't know. The GPIO on the Amlogic devices is quite a bit different. I don't vary from the stock device tree most of the time, so other than the spidev I added it will reflect (assuming I read the schematic correctly, and it in turn was correct) I've been meaning to do it for some time, but I'm just starting working on documenting some of the GPIO's and their various functions. So, in the device tree if you enable UART A, you'd have the port you want. Unfortunately my wizardry does not include device tree overlays yet, however this may be something that's ok out of the box if the vendor image has it configured. (clarification: I can make a static change to the device tree, however for these sorts of things dynamic changes via overlays is better) It's also good to see @adafruit doesn't sleep either. However, I will be going, back to paid work in 6 hours.

Yes. ttyAML0 is the console. The Hardkernel documentation covers the really old 3.14 (now 3.16 I guess) kernel, it was different. Debian GNU/Linux 9 odroidc2 ttyAML0 odroidc2 login: The downloads I linked are CLI images with buggy HDMI. The spidev is a new feature for this and the NanoPi K2 (same SoC) with Armbian, I have not done much testing so far. Using the uart that won't be an issue though. Let me look at the gpio uart, it can be enabled of course, it's most likely just gpio at the moment.

Howdy Adafruit, Kernel 4.18 does not have this implemented, it is a software SPI on these boards so limited speed. if you are working from the serial terminal you can use 4.19 now, the HDMI is a bit buggy at the moment: https://dl.armbian.com/odroidc2/nightly/ On kernel 4.14+ Amlogic devices, the uart is ttyAML0.

I'm going to poke at it and try to add a Tritium board to it since I have them. Then maybe a Duo or Neo/core. I have enough gadgets to test it out ok.

I run my home server on an Odroid-XU4, the original form factor for the Odroid HC1. I can throw my support behind that platform. - File Server - Plex Media Server Current up time is 72 days, I usually do a reboot after running updates.

Yes, this is known issue. The only screen I have that comes up with HDMI without issue is a 7" RTD2660H device. Power it on without a monitor plugged in and plug it after, that may work until the issue is resolved. Hmmm, I did not see this, but I was going between 3 boards. Will check. Correct, the only one in the family we currently support with WiFi is the K2

Igor and I've put in a bit of time on the 4.19 LTS kernel in Dev, nightlies are being built: https://dl.armbian.com/tinkerboard/nightly/ I've been running one all day, so far works like a charm. Wifi/BT/HDMI/USB hotplug/onboard audio all seem to work, if we can get some testing by others to verify it would be greatly appreciated, the goal will be to roll this out to Next once any bugs are squashed

@martinayotte I'll take another round with it as well if you provide examples. @giminni The issue here is that we have a small pile of rk3399 boards that boot just fine using "flow 1". Even if we get "flow 2" working, the question as to why it has to be different and clutter up our build system remains.

Behold the @chwe! He brought light to the Goo! I see no downside to fluorescent mice and rats, as long as the genes don't make them poisonous to all the benefiting cats.

https://www.merriam-webster.com/dictionary/masochism (I would recommend sticking with definition 2. Although it's tough these days to know for sure...)

I try to eat organic when available and cost effective. I also grow my own vegetables in the summer. I also cut all the high-fructose corn syrup and a lot of sugar out of my diet, unless I need something to mix my rum or whisky with. Playing with genetics seems a risky game, but then again scientists love diving into the unknown and the loud ones live lives of pure hubris, thinking their tiny addition to the sum of humanity's knowledge somehow makes them a god.

@sgjava I've put spidev with both chip-selects on the C2 and K2 in the expected spi0 position for the dev kernels. We'll see about images here in a bit. @Igor gets to make that call.