RFC Tinker Board UART number

[TonyMac32]

For some reason the default UART utilized by uboot is uart2 on the Tinker.  I haven't messed with it, and left it alone, but vendor uses UART1, and UART2 has a conflict with PWM pins.

 

I'm in favor of changing, if anyone objects or has a more interesting idea, please discuss.

[Tido]

With regard to that conflict of PWM, this change sounds reasonable to me. No objection, sir.

[JMCC]

15 hours ago, TonyMac32 said:

but vendor uses UART1

They changed it to UART3 in their latest 2018/03/20 release:  https://www.asus.com/uk/Single-Board-Computer/Tinker-Board/HelpDesk_Download/

https://tinkerboarding.co.uk/forum/thread-1198.html

 

In my opinion, provided that it does not conflict with anything else, if we are going to make a change I'd rather choose UART3,  in order to make it easier for people moving from one OS to another.

 

I just got a USB to UART adapter. These days are very busy for me, but I can do some tests after the weekend.

[TonyMac32]

5 minutes ago, JMCC said:

They changed it to UART3 in their latest 2018/03/20 release

 

Good catch.  It could be because only Uart1 has cts/rts from what I can tell, and that might be needed somewhere besides a terminal...

 

Quote

18. Use Device Tree for DSI Touchscreen

Hey, that was me! 

[Tido]

No. 18 - well done @TonyMac32

13. Improved Xorg performance when dragging windows  - sounds interesting, is this for 4.4 Kernel ?

 

It looks to me ASUS has done quite a bit, even with support of the community, but in opposite to SinoVoip @Nora Lee they improve their download images on a regular basis

[JMCC]

2 hours ago, Tido said:

Improved Xorg performance when dragging windows

I think it is not kernel related, but about the Rockchip custom X server. I would assume that, since in Armbian we are using the latest version from Rockchip GIT, we have already incorporated that improvement. But that may not be the case, since there was a dance of commits being applied and reverted, and I am not sure whether the latest version has incorporated the change or not. I think the best way to find out is to compare Armbian and TinkerOS performance with benchmarks like GTKperf, and by simply using the UI and seeing how it feels. More info here: https://github.com/rockchip-linux/rk-rootfs-build/issues/25

 

2 hours ago, Tido said:

they improve their download images on a regular basis

That is very true. The only problem I find is that you cannot upgrade "the Debian way" to newer versions: you always need to reflash the whole OS. Even more, sometimes they explicitly tell you not to do an "apt upgrade" since it may break the system. That is not a big problem if you use your board only to set up a specific DIY project and leave it running without touching anything, but limits its usage as a regular OS (e.g. if you use your board as a server, you'll need to be able to upgrade regularly for security patches, without needing to reflash and reconfigure the whole OS).

[TonyMac32]

On 3/31/2018 at 6:35 AM, JMCC said:

The only problem I find is that you cannot upgrade "the Debian way" to newer versions: you always need to reflash the whole OS.

This is a running problem with a lot of vendors.  If the Tinker Board kernel was less specific to the Tinker, I'd use it directly and we'd have a lot less work to do "keeping up".  But the handling of some of the hardware issues causes their kernel to crash other boards.  At the moment I need to see about submitting some of the patches I use now to Rockchip, most do not affect other machines and can be merged easily.

 

Hmmm, I tried the newest image with only the DSI screen attached, it locked up and started flashing the display after starting the web browser...  <---- the download link on the product page still gives you 1.8, I didn't pay close enough attention, beware of that if you dl Tinker OS!

[jkljkl1197]

i am for too !!!

[TonyMac32]

It looks like they may be avoiding the exposed 8-bit TS interface they have on the board.  I saw a driver for it hit the Rockchip kernel, not sure if any hardware exists to make use of such a thing.  I'll do a quick test on relocating the uart, but I can't promise this will be a simple update for existing users, they may need to modify scripts manually.

[chwe]

On 31.3.2018 at 12:35 PM, JMCC said:

That is very true. The only problem I find is that you cannot upgrade "the Debian way" to newer versions

On the other side, people are frustrated when @Igor bricks some builds by pushing some stuff to apt.armbian.com  I don't know how many full time employees are working to maintain the tinkerOS and how experienced they are in maintaining such a system. Besides their AAEON Up boards (x86 architecture, from a different business unit), it's the first time that they dive into this market, and I think they perform not bad for a 'newbie'... In the long term, I think in it would save them a lot of time to stay with RKs upstream kernel with patches (as we do with armbian), cause RKs userspace stuff (e.g. gstreamer) evolves too and might be incompatible to their kernelfork in the future.

But this is a nice example to show all the efforts which are needed to bring up a project like armbian. There aren't that much boardmakers which maintain their boards closer to upstream as armbian...  Btw. @JMCC, I appreciate your efforts in the whole hardware accelerated multimedia stuff. IMO because of that, the tinker is one of the few boards which can be suggested as a 'multimedia armbian board' (even when my personal interests in multimedia is minor -  the reason I own a tinker was because they didn't sell well here and were on discount for a long time..  40$ ~a year ago, now ~70$ ). 

 

@TonyMac32 did you check, if there's a (easy) possibility  to get serial console silent from userspace (uboot and kernel, without recomplilation)? I've in mind that there's a silent mode which can be activated during compilation  (u-boot) but I never tested it. Reason: when people start to play with hats, it might be needed to keep it silent to avoid conflicts with the hats (even when I think that a silent console is a bad idea..  ). 

[jkljkl1197]

[ warn ] * [l][c] 220_uart4_fix.patch [ failed ]
[ warn ] * [l][c] 04-patch-4.4.114-115.patch [ failed ]
[ warn ] * [l][c] 04-patch-4.4.115-116.patch [ failed ]
[ warn ] * [l][c] 04-patch-4.4.116-117.patch [ failed ]
[ warn ] * [l][c] 04-patch-4.4.117-118.patch [ failed ]
[ warn ] * [l][c] 04-patch-4.4.118-119.patch [ failed ]
humm?

[JMCC]

11 hours ago, chwe said:

I appreciate your efforts in the whole hardware accelerated multimedia stuff

My pleasure. I entered the world of SBC's four months ago, when I got a Tinkerboard for a multimedia-related project (a programmable video and announcements player for a TV in my church).  I only knew about the Raspberry Pi, but I did some research and learnt it was not powerful enough for 1080p video.  So I found myself in front of a myriad of different Chinese fruitty-pies, another brand called "Odroid" which I assumed would only run Android (), and a more powerful Raspberry Pi clone from ASUS.  I said "what the heck, if it's from ASUS it must be good, and it will also fit in the RPi case I already ordered". So I went for it (it was also on a special offer before Christmas, 55€ with free shipping). 

 

I had not used a Linux desktop in quite a few years, but turned out that X had not changed much since (which proves that it is obsolete ), so it just took me a few nights to figure out how to squeeze the most out of that little piece of hardware. But, still, all the Tinkerboard OS's looked to me more like compromise solutions to make the board work, rather than real OS's I could trust. Until I came across Armbian, that appeared to me more like the real Linux distros I was used to in the past. I saw committed people who really knew what they were doing, and it gave me a feeling of reliability.

 

Thanks to Armbian and other projects like DietPi, I learnt about other possibilities for SBC's, such as home NAS, Wifi hotspot or VPN tunnel. That encouraged me to get an OPi+ 2e first, and an Odroid HC1 later: Armbian reviews and comments taught me that those were good choices.

 

So I wanted to share the little I had learnt about multimedia in ARM SoCs, and @TonyMac32's announcement that he was switching to the Rockchip kernel seemed like a good opportunity to do it.  And, most important, what really motivates me is that I have found there is a lot of good people in this community, and I really enjoy participating in it! So, as long as I am able to contribute in any way, I'll be most glad to do it! 

[jkljkl1197]

sound/usb/pcm.c: In function ‘set_sync_ep_implicit_fb_quirk’:
sound/usb/pcm.c:361:2: error: duplicate case value
  case USB_ID(0x1397, 0x0002):
  ^~~~
sound/usb/pcm.c:352:2: note: previously used here
  case USB_ID(0x1397, 0x0002):
  ^~~~
scripts/Makefile.build:277 : la recette pour la cible « sound/usb/pcm.o » a échouée
make[2]: *** [sound/usb/pcm.o] Erreur 1
scripts/Makefile.build:484 : la recette pour la cible « sound/usb » a échouée
make[1]: *** [sound/usb] Erreur 2
Makefile:1016 : la recette pour la cible « sound » a échouée
make: *** [sound] Erreur 2
hummm i don't know but i delete the build folder and when a i compile each time i get this error

[TonyMac32]

Let me take a look-see.  Are you use the development branch? 

[jkljkl1197]

Full os image for flashing
do not show kernel config
tinkerboard
default vendor provided legacy 3.4.x to 4.4.x
xenial
image with desktop environement

i try to delete the build folder and redownload build git do the same it's special
i am on Hyper-V with the minimal image get from doc of armbian on ubuntu studio on graphical (to compile) but it's change nothing i think, it's working before the new patch/version.

nope

[TonyMac32]

Ah ok,

 

Stuff LIB_TAG="development" into the config-default.conf file to use the active dev branch. 

 

 

[jkljkl1197]

yeah now it's work well

damn before it's taking to me 1h30 and now 3h i need to add some cpu core to the vm

[jkljkl1197]

Just to be sure the uart as been already change to uart4 on main branch and developper branch for thinkerboard? or i need to do something to change it. Thanks guy's

[TonyMac32]

I will be testing this change tonight or tomorrow, it was put on hold because it presented problems for the MiQi, but I since learned I can make per-board U-boot patches.  I will update here on completion.

[TonyMac32]

OK, development branch will reflect the change, on existing installations you will have to manually add

console=ttyS3,115200n8

to the armbianEnv.txt file in /boot.  I did a tiny bit of house cleaning as well, putting the Tinker u-boot patches into a board-specific directory so they don't impact the MiQi.

[jkljkl1197]

perfect thank you @TonyMac32