TonyMac32

Seems to be an RK33xx issue, the RK3288 is 115200 like any sane serial terminal. tell me about it. Agreed. I agree. I'm not against "slightly different", I just need to see stable. I don't want a "commit bomb" destroying my kernel config and making it impossible to repair without major issues.

Whoa. I've burned a few of these SD cards 50 times or so with Etcher and never had that happen. Is this a Windows/linux/Mac host?

I am uncertain. I need to spend a lot of time with Rockchip, with their last few rounds of updates they have become quit "Special" as far as their BSP is concerned. I'm hoping this is temporary and it will stabilize (perhaps they are reaching a tagged release, which I will stick to once available) The Tinker OTG does not appear to function as I would expect, I do not have complete schematics to know if there is a GPIO needed/etc, getting OTG is a (personal) goal of mine because it is the only dedicated line not going to a soundcard, and so would allow for a better performance for a dedicated drive/etc when properly powered. Things I know about the OTG: -Rockchip maskrom works as a device without issue (means the controller is attached to the SOC. -Reportedly the OTG line input is attached to the SOC as well, menaing it should be able to tell when a device is attached and use the proper mode. - It does not do the above... The Android code DTS handles these things quite differently, I can poke around in there at some point, but not any time incredibly soon.

Tearing the engine out of my truck and fixing the timing chains today, waiting to see a pull request from any of the poeple who want to see a Tinkerboard camera work out of the box, defending why I bother with a lot of this stuff for no compensation with my wife. I haven't gotten the undocumented mess Rockchip made completely sorted out yet to even begin casually looking at the camera.

armbianmonitor -u output please, and

Is this a reboot or a new power cycle?

I was re-reading this, did you check to see if you can enable the clock in the device tree? Zador mentioned that early on, but I only saw the userspace memory stuff going on. I don't have any R16/33's anywhere to play with them, unfortunately.

Rockchip uses something like this in their BSP kernel, but from my experience it is a bit buggy and looked like a lot of work. It's probably not a path worth going down.

@Neil Armstrong I did a quick test, with my very primitive boot script I had a problem booting, uncovered: U-Boot 2018.07-rc1-armbian (Jun 12 2018 - 22:07:39 -0400) nanopi-k2 DRAM: 2 GiB MMC: mmc@70000: 0, mmc@72000: 1 In: serial@4c0 Out: serial@4c0 Err: serial@4c0 [BL31]: tee size: 0 [BL31]: tee size: 0 Net: Warning: ethernet@c9410000 (eth0) using random MAC address - 46:75:fe:24:98:2d eth0: ethernet@c9410000 Hit any key to stop autoboot: 0 => mmc list mmc@70000: 0 mmc@72000: 1 It's trying to use the WiFi as mmc 0. I only avoided this because I didn't have the wifi in my device tree (had errors). I don't know if defining the boot targets per board would help since mmc 0 will always be the WiFi, unless the numbers are unrelated between that #define and the resulting environment assignments... Otherwise good to go, and I would guess this shouldn't be a problem for properly written scripts

https://github.com/armbian/build/blob/master/packages/bsp/rockchip/start_bt.sh Is the Realtek 8723bs way to do it on the tinker board. You might have to worry about the clock as Zador said, and if you look at this, typically driving reset low is the "in reset" state, letting it go high is active.

On tinker board we would up using a script to toggle the resets/etc, once the reset was done then hci attach was performed. I would recommend toggling the resets because you may want to disable/re-enable, and that has to be done for each cycle.

Please provide armbianmonitor -u link so I can get the useful information.

Wow. Two things I've never had to deal with:. Import taxes and crazy delivery guys.

Thanks @Myy. I saw that a bit ago but haven't had time to go through and update 4.17 patches.

Yes, however flawless video decoding doesn't do you much good if it gets written to the screen in torn and incomplete frames. (Unless you're transcoding/converting headless or something) So while the drivers are unrelated code wise, their functions complement, and I'm pretty sure I read a comment about Lima in the Bootlin updates, which is why I mentioned it.

Well they should know, I would hope. :-P. But then again their updates to the kernel rendered our kconfig not only not booting, but not even building... 10 days with no Rockchip feedback of any kind on the issue, I think we've been more helpful to hem than they to us. The GPU error is still there, but it seems to only involve the power model and the functionality still works. I haven't tried to re-enable the touchscreen yet, next on the list, that *should* bring us back to feature parity.

@Neil Armstrong I forked the current github u-boot and adjusted for the renaming of gxbb to gx, I've been focusing on Rockchip for testing last several days so I won't gauruntee no typos, and the readme is incomplete, needs the details about where to get blobs and the fip script. Https://GitHub.com/tonymac32/u-boot I just used the generic gxbaby blobs here so far, that shouldn't have anything to do with the temperature readout should it? I haven't spent a ton of time debugging, the memory allocation patch I'd applied to the kernel a while back unfixed itself as adjustments were made upstream and I abandoned the old bootloader. I see some patches in there now to address it, but I figured mainline was a better solution for my sanity and our uses here.

@igor I will take a look at 4.17 later today and let you know, my typical test time with it got taken up by Rockchip kernel shenanigans. I thought we were sticking to lts on shipped images.

I think this is thankfully not the case, the IR drivers are inherently just serial input. From there, however, I don't use them so I know nothing more.

@Robertspark OK, I'm in the middle of some other stuff, so I encourage you to try to burn a new SD card to test this, then use http://electricgraveyard.com/armbian/tinker/uboot/linux-u-boot-tinkerboard_5.46_armhf.deb Install it with dpkg -i <name of package>, then verify it boots and can install to eMMC/boot. I've been running an S off of eMMC for a while, it was a simple patch but it hasn't gotten into the images yet, especially after the Rockchip kernel (4.4) went sideways with the most destructive commit bomb ever.

The issue is u-boot itself. give me an armbianmonitor -u off of the SD card. U-boot has been patched, but packages may need updated. At present the 4.4 kernel is broken because of some rather extreme upstream changes with limited documentation.

@Ondřej Glogar I am going to say that for myself no, I won't be supporting this board. The lack of engagement by the other devs tells me they have no plans either. Without additional devs I think we're probably at a critical mass for number of platforms and "unique" boards.

https://github.com/rockchip-linux/kernel/issues/98 Anyone else who is building/working with this kernel, here is my open issue, 7 days with no feedback from Rockchip.

https://wiki.linuxfoundation.org/realtime/start 4.14 patch is development. I built a couple images that way , never got to the point of testing them out because real world problems didn't give me the time to use my experimental solution. Proceeding as Igor suggested this is actually relatively simple with the mainline LTS kernels. Add patch as instructed. compile and update kernel configuration accordingly (hard preempt, etc) profit. there are some tests available on the realtime wiki that can tell you if it's working or not.

Well, the frustration of course comes form the fact we gave you the status, and the fact that current "big issues" we're preventing any work. No offence meant to you, but we are too small a group to take requests when the kernel is burning. ;-). Currently work is underway to make the kernel boot correctly. That's how different/possibly broken the Rockchip update is.