TonyMac32

I have not had an issue like this, I am downloading the image from the site to test further. What peripherals are attached, and any software installed? [edit] I was unable to replicate this issue with my 2 boards.

That's what I've been hearing, especially concerning ddr4. I have a board coming, and a heatsink. So I can give some comments on the design/etc later on. My assumption going in is, other than RAM and a few pins, this should be virtually identical to Rock64. RK805/RK3328/GbE/Same USB setup/eMMC/etc. The big difference is the RAM.

Well, right. In this case, I think it's easy enough to say everything gets dumped into development by default, I was just trying to make sure I in particular didn't create a giant git shitstorm. . I agree that this sort of thing needs discussion and agreement, with an emphasis on scaling to this project. Professionally working in the automotive industry, I will be the first to throw a flag if anything is too complex or overbearing, since I would rather this not go down into that abyss. For u-boot, I'd honestly never change it unless our scripting required some new feature or a board was still in the process of gaining support (Tinker S needed a patch to U-boot on Rockchip, so whenever it is properly supported I'd ideally test then update. Of course rk3288 is exactly 2 boards, not exactly a Herculean task to test. With H3 I can see it being a royal pain. I would go conservative enough to say it would have to have a proven benefit. Especially when our boot packages only cover a portion of the story, the boot scripts themselves depend on the binary, and user edits are something whose compatibility with upgrade you cannot test. That is what I intended with Meson64 and Rockchip, jumping LTS to LTS.

OK, I have that GPIO base update for rk3288 default, Rockchip went to a base 1000 which breaks all the GPIO libs people use, I wanted to get that pushed through. But, as it is now 3:00 AM here (time changed on me while I was working), I'll have to wait.

I was looking for the config, came across only https://cateee.net/lkddb/web-lkddb/HID_EZKEY.html Which, honestly, probably isn't the answer...

With the addition of the development branch, how do we want to handle bugfixes? Should I apply to development and then cherry pick to the master branch?

Glad to hear that is working properly. This becomes a bit more problematic, as I have 2 test monitors in my lab/workshop: A Samsung 4K monitor and an extremely cheap Acer 1080p monitor. Both work flawlessly with this kernel, so I will have a difficult time debugging this issue. can you provide me the output of running the command xrandr?

Those are the two patches that solved the issue on mainline. It is possible the code isn't as directly portable as it appears. Have you raised this as an issue with the LibreElec team? (Or whoever's fork directly supports this board)

If you can compile it yourself I have that fixed in the build system, it was a u-boot issue. [edit to clarify the brief answer] This board was moved from a "wip" (work-in-progress) to a "csc" designation, meaning community support only, it is not a future target for Armbian. This is due to a combination of factors including manpower and general community interest.

Assuming you can handle BGA, on a first run use a processor we support like H3. Sent from my Pixel using Tapatalk

I'll get that fixed later today.

I just caught up on this, I think this will be due to not rolling back the base 1000 change from Rockchip. I did not notice that right away, it's certainly an unexpected change... tony@tinkerboard:~$ ls /sys/class/gpio export gpiochip1024 gpiochip1088 gpiochip1152 gpiochip1216 unexport gpiochip1000 gpiochip1056 gpiochip1120 gpiochip1184 gpiochip1248

Use a USB wifi dongle and try again, that is the image with the faulty ethernet drivers. After update it will be stable. [edit] If you haven't done a lot of configuration, the download page will give you a 5.38 with kernel 4.14.14. How long ago did you download the image you have?

I will try building it without any extra patches to see if it works that way. If not I will reach out to Rockchip concerning the issue.

The userspace GPIO driver is not implemented yet, so root is necessary.

I think I'd probably get a stomach ulcer in fear of screwing it up... ?

I've hit the same wall you have, I'm getting a kernel oops as the first thing that happens, tied to the ISP1 driver. Nothing is particularly different about the device tree between tinker and firefly, and as you pointed out, someone claimed to have gotten it working on firefly... Tomorrow I will investigate any changes that were made to the other camera drivers that may not have been made to the rpi cameras... [edit] of note, it happens on both cameras, same fault, so it is either a common error to the 2 drivers, or it is the isp1 driver itself. This is of particular interest as the same configuration is required for the rk3399.

I think running apt update and apt upgrade should give you 4.4.117 or 119 since the new image came out. @Igor the repo was updated, correct? If not, the link I shared in the new kernel testing thread has the most recent kernel packages in it, with the audio updates. Install those, verify you have 4.4.(newer than 112), then reinstall all the files you deleted, they are necessary. (I'm working off my phone at the moment, I apologize for curtness or spelling errors) Sent from my Pixel using Tapatalk

If you are using mainline kernel (4.14) you have to follow the instructions detailed in the thread dedicated to Tinker Board sound, that update has not been rolled out yet. If you are using 4.4 kernel you should, after installing all the files, simply have to apt update and upgrade now. Sent from my Pixel using Tapatalk

New 4.4 based images were released containing the updates. Sent from my Pixel using Tapatalk

Glad you were able to clear that up!

Hmmm, what is the armbianmonitor -u look like when it boots? :-P. I should have my cameras in a matter of hours, so I can join in in the confusions. :-)

Hmmm, wasn't what I'd hoped. I'll keep digging.

Well for me it is the boards with actual hardware errors, which, sadly, is also the Tinker Board with that reboot issue, it was quite a pain initially to fix without breaking any other board supported by the same kernel. I am unconcerned about people not understanding electricity and getting confused, as long as we have moderators *ahem* to deal with them. Well possibly, although I would argue that any patches going into the main kernel patch directory for a given kernel should be "board agnostic" and be things like device driver additions/updates, dtsi/dts bugfixes, etc. For a specific board then, come the "ugly" hack job patches, that would be a problem to maintain no matter where they were. That BPi patch, the tinker reboot, tinker touchscreen (before I stuffed it into the device tree), probably tinker camera, etc.