RK3328 Kernel

[patrick-81]

On 27/01/2018 at 6:23 PM, patrick-81 said:

Hello all,

I have initiated this project months ago : https://github.com/Patrick-81/NAFABox

I had on previous version of Armbian (5.32) solved (partially) the wifi instability. Today with new version whatever I do, the wifi remain instable.

Furthermore I tried to drive a focuser directly from the GPIO extension port. But I can't use it because of a leak of privileges.

To make it work I need the /dev/gpiomem public access.

I saw that it might be implemented in the last version of TinkerOS (2.0x). Will it be implemented in Armbian next versions ?

 

Because of this two problems my project remains not completed.

 

DO you think that both pf those issues can be fixed a=in a near future ?

Back with my problem of gpiomem public access. Does anybody can help ?

[TonyMac32]

12 minutes ago, patrick-81 said:

Back with my problem of gpiomem public access. Does anybody can help ?

You are talking (somewhat impatiently) to him.  My priorities are bugfixes, then features, I've had a few bugs to look into since releasing the new kernel to the wild.  This should be a very simple update, I will post in this thread when it is implemented, should not be long, hopefully I can roll it into a bugfix release for the board. 

 

As is rather lengthily described elsewhere, this is a project run by more or less volunteers for limited compensation of any sort.  I have been unimaginably grateful for the help I've received getting/keeping this board running, but at the end of the day I am a man, not a wizard, and have only so many hours and so many coffees.  And a wish to keep my wife...   

[patrick-81]

Sorry Tony, but as I haven't got answers about my question that is why I asked it again.

If I have been able to do it by myself I would have. But unfortunately I don't have the knowledge to do it.

I thank you for the help you provide to all the linux users community of this board.

 

 

[TonyMac32]

No worries, I'm fighting off a nasty respiratory infection at the moment and haven't been able to focus properly.

 

[TonyMac32]

Something new to me is a growing list of "we work with Tinker Board" accessories on Amazon:

 

https://www.amazon.com/gp/product/B078WK1R2R/ref=pe_3444240_275372910_em_1p_4_im  I am more than a little amused by the size of that fan... 

Of course remember my solution to throttling...  4x the heat sink and a tiny fan.

 

 

The reason I didn't post any others is that I wouldn't recommend any of them.  None of the supplies are specific about output voltage (if 5.0, just say no) and most of the cases are just rebranded, and many would cause a lot of pain and suffering if you are looking for performance.

[chwe]

1 hour ago, TonyMac32 said:

Of course remember my solution to throttling...  4x the heat sink and a tiny fan.

haha, my box cooler doesn't stick well anymore.. Since the BBQ session when the SoC wasn't touchable for a whole night... 

 

but your set-up looks much more professional than mine..  

 

5 hours ago, patrick-81 said:

Back with my problem of gpiomem public access. Does anybody can help ?

you can test it by applying this PR and build it on your own:

https://github.com/armbian/build/pull/907

 

4 hours ago, TonyMac32 said:

not a wizard,

keep rocking breathless (wolo)wizard...   (the day Igor gives you mod rights here, I get kicked out.. )

[TonyMac32]

3 minutes ago, chwe said:

(the day Igor gives you mod rights here, I get kicked out.. )

A good reason for him to not give me such rights and let me stay free. 

[HackXIt]

I did the usual 'apt update' and 'apt upgrade' but apparantly I'm still at version '4.4.112-rockchip'.

I was wondering if these warning messages I've recieved during the update are maybe related to anything of that?

dpkg: warning: unable to delete old directory '/usr/src/linux-headers-4.4.112-rockchip/scripts/mod': Directory not empty
dpkg: warning: unable to delete old directory '/usr/src/linux-headers-4.4.112-rockchip/scripts/kconfig': Directory not empty
dpkg: warning: unable to delete old directory '/usr/src/linux-headers-4.4.112-rockchip/scripts/dtc': Directory not empty
dpkg: warning: unable to delete old directory '/usr/src/linux-headers-4.4.112-rockchip/scripts/basic': Directory not empty
dpkg: warning: unable to delete old directory '/usr/src/linux-headers-4.4.112-rockchip/scripts': Directory not empty
dpkg: warning: unable to delete old directory '/usr/src/linux-headers-4.4.112-rockchip/arch/arm/include/generated': Directory not empty
dpkg: warning: unable to delete old directory '/usr/src/linux-headers-4.4.112-rockchip/arch/arm/include': Directory not empty
dpkg: warning: unable to delete old directory '/usr/src/linux-headers-4.4.112-rockchip/arch/arm': Directory not empty
dpkg: warning: unable to delete old directory '/usr/src/linux-headers-4.4.112-rockchip/arch': Directory not empty
dpkg: warning: unable to delete old directory '/usr/src/linux-headers-4.4.112-rockchip': Directory not empty

Also just to clarify:
I've edited the file /etc/pulse/default.pa with the modules listed in the repo-file you posted as well as copied the asound.conf from the repo into /etc/
Are those locations correct?

 

I like the case you've posted (which I would certainly buy if I had the bucks atm), but I'm fine with my current solution below for the while being^^
My "cooling" solution

[Igor]

1 hour ago, HackXIt said:

I was wondering if these warning messages I've recieved during the update are maybe related to anything of that?

 Warnings are usually safe to ignore. Those are.

[patrick-81]

On 12/03/2018 at 3:09 AM, chwe said:

haha, my box cooler doesn't stick well anymore.. Since the BBQ session when the SoC wasn't touchable for a whole night... 

 

but your set-up looks much more professional than mine..  

 

you can test it by applying this PR and build it on your own:

https://github.com/armbian/build/pull/907

 

keep rocking breathless (wolo)wizard...   (the day Igor gives you mod rights here, I get kicked out.. )

Hello,

After having done the mods I have compiled all successfully. And tadaam, now all works fine. I finally have user access to the GPIO.

A very great thank to all of you guys.

Hope those patches will be part of the official release of ARMbian.

Best regards

Patrick

 

[TonyMac32]

 

[Frostbyte]

Has anything been changed, in regards to stability or voltage control, with the last couple of kernels?
My board is being surprisingly stable, currently with an up time of 35+ days. *knocks on wood*

[TonyMac32]

1 hour ago, Frostbyte said:

Has anything been changed, in regards to stability or voltage control, with the last couple of kernels?

Well, that depends which kernel you are using.  "Default" kernel 4.4 was moved to the Rockchip repository, which provided a huge number of bugfixes/adjustments/new drivers.  4.14 has simply seen the typical maintenance patching.

[JMCC]

3 hours ago, TonyMac32 said:

"Default" kernel 4.4 was moved to the Rockchip repository, which provided a huge number of bugfixes/adjustments/new drivers. 

And more fixes were added by Armbian too! Just the mali4xx/mali-midgard conflict was causing a flood of error messages in syslog, until @TonyMac32 found it and fixed it.

[Frostbyte]

That's very nice to hear! Good job everyone!

[TonyMac32]

OK, mainline wifi appears to be having troubles, please ad comments/observations In this topic I just created

[TonyMac32]

For some better news, Bluetooth is now in the development branch for default and Next kernels. 

 

To DIY this change, look at:

 

https://github.com/armbian/build/commit/ac8d0d86687007c894caf18b0ba85d99c38eb8b1

 

and

 

https://github.com/armbian/build/commit/daf80053e8a1eda8ee2f95d879ec525f1d92fbe0

 

device tree changes are the most complicated part, or build and apply.

 

The device tree changes will break the functionality present in existing installs until the service/script are added.  In reality the BT as it is today is somewhat broken, the new implementation is so far superior in every respect.

[Z11ntal33r]

Hi guys!

The Tinkerboard mainline kernel is running extremely smooth and it's months since I had problems regarding my Tinkerboard. So, hats off to everyone who have contributed to make Tinkerboard so stable and reliable!

However, there is a minor thing I've been wondering for the last weeks. After normal apt-get upgrade and dist-upgrade, the armbian config version at startup does not change. So, given the code below, it says that Armbian-config 5.45 is installed, yet it show 5.41 which is the version from when I did setup the TB. Am I actually using the latest version? 

One more thing: On my last setup one of my three external hard drives which I'm mounting on startup with fstab showed up under "Usage of /:" Now no one of the three show up. Which file do I have to modify to make it possible to add more folders to show disk space at the welcome screen? I know that I receive the information running "df -h" to show disk space for different folders, yet it would be better to show it automatically.  

The following packages will be upgraded:
  armbian-config
1 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
Need to get 35.2 kB of archives.
After this operation, 0 B of additional disk space will be used.
Get:1 http://apt.armbian.com stretch/main armhf armbian-config all 5.45 [35.2 kB]
Fetched 35.2 kB in 0s (102 kB/s)          
(Reading database ... 39453 files and directories currently installed.)
Preparing to unpack .../armbian-config_5.45_all.deb ...
Unpacking armbian-config (5.45) over (5.44) ...
Setting up armbian-config (5.45) ...
________________________________________________________________________________
*** REBOOTING SERVER ***
________________________________________________________________________________
*** AN AWESOME TINKERBOARD LOGO ***

Welcome to ARMBIAN 5.41 stable Debian GNU/Linux 9 (stretch) 4.14.34-rockchip   
System load:   0.06 0.11 0.06  Up time:       4 min
Memory usage:  8 % of 2005MB IP:            <MyIP>
CPU temp:      45°C           
Usage of /:    65% of 58G    

 

Update:

@TonyMac32, could you help me regarding where I should post the information above to receive an answer from the devs maintaining the armbian-config? Should I post it under "Technical support -> Common issues" or "Development -> Development"?

 

[Igor]

On 5/16/2018 at 9:17 PM, Z11ntal33r said:

Am I actually using the latest version? 

Yes, you do. Sometimes, rarely we push update only to some critical sections. In this case, only armbian-config was updated, while Armbian internal number or a majority of packages remained the same. A version number is taken from BSP (board support package). This means it won't change until that package gets an update. This usually happens at the major upgrade. 

Nothing to worry.

If you find some specific problem with armbian-config, the best way is to open an issue ticket here: 

https://github.com/armbian/config/issues

[ecropolis]

Wifi Instability Issues on Tinker Board RTL8723BS

I got a fresh Tinker Board about 2 weeks ago and set it up with Armbian Next (4.4.23). I was able to connect to wifi with a single nmcli connect command and no problems. I've left it running mostly - I've done a lot of different installs but nothing outside of typical utilities and whatnot - the only networking software I have is the Hamachi client and I did also install Docker to experiement with.

 

I wanted to test the ability to connect to a different Wi-fi network.  This is where the problems start. I'm unable to connect to another SSID. On fail it doesn't re-connect to the previous one. I try to issue nmcli con up 'myssid' and that doesn't work. I try to restart networking and network-manager. I try to deactivate the adapter and re-activate.  Nothing works other than a reboot. But now when I leave it and come back an hour later it is continually back down. At times I'm not even able to do 'nwcli dev wifi list ' and get any results and I should be seeing a half-dozen SSIDs out there; two of which are mine and 90%+ signal strength so it seems like even the radio is dead... but then oddly enough sometimes I'll rescan and get ONE weak signal hanging out.  I have also checked rfkill throughout the process and I've never seen any issue there with adapters being disconnected. I also tried removing (nmcli delete) of all wifi entries and then doing fresh connection commands. No matter what I do, it's broken. The only attempt I really made towards a fix was that I found https://github.com/hadess/rtl8723bs and here I ran the convert_firmware.c script and then replaced the .bin files in /lib/firmware/rtlwifi -- I got zero change in behavior other than some messages in syslog warning me that I was using a staging driver (I am not sure I did it right but it didn't seem to make anything worse off). Reboot, it's up. An hour later, or less, it's down and can't get the connection back up. I'll also add here that really the first thing I did out of the box was install the TinkerOS. I have to report that the Wifi kept dropping and since it has an Xterm I would get prompted for the wifi passkey. I didn't investigate much further on this; sometimes it would stay connected for a few minutes and then it might stay for an hour or two. I switched to Armbian - however I do still have that TinkerOS image on another SD card and I did double check that it's using the same driver.

 

I just tried installing Armbian (4.14.52) again fresh to a fresh SD Card. I ran my installers which included Hamachi as well and again I have the same problems.  (Although I'm not sure if I'll have the stability problems but for certain I have the issues of not being able to change connections or re-activate a connection that is down.

 

Errors in syslog that stands out through all this:
Association request to Driver failed

Activation: failed for connection 'mywifissid'

Activation: (wifi) Association took to long Failing

Policy: disabling autoconnect for connection 'mywfissid'

wlan: link is not ready

Another is that sometimes I get SSID Not found but then doing a rescan / list it's clearly available.

 

I'm worried -  I was really loving this board for what I'm working on but this might be a deal breaker for me. Not sure if it's worth it to have to get USB Wifi on my devices in order to use these. They're going into headless, hard to reach places so I have to have a stable connection.

 

[TonyMac32]

The mainline staging driver is quite old base source, while it has gotten a lot of attention, I think it still has some issues.  The latest Tinker OS (and until the issue with upstream Rockchip, Armbian Default) uses a brand new driver with some bugfixes.  I am trying to establish what has and hasn't been included in the "snapshot" source package we've fallen back to while Rockchip's kernel is sorted out (or not), and will be rebuilding from there.  As it stands the 4.4 Armbian build currently available is a newer driver than used in mainline.

[ecropolis]

Would it make sense to try and take driver files out of TinkerOS and replace?

I think it's just the files here right? /lib/firmware/rtlwifi 

(just learning an finding my way around various issues as they come)

If I did that - when things do get updated would they just be overwritten when doing apt-get upgrade && apt-get update

Thanks for your attention to it. Good to know!

[Myy]

`/lib/firmware/rtlwifi` only contain the firmware themselves. Though, you could test if a new firmware gets you a better connection. For that, be sure that the name of the new firmware  is equivalent to the old one. Try `dmesg | grep -i bin` to get a clue of which firmwares are loaded by the kernel.

[ecropolis]

For what it's worth I think the RTL8723BS driver in TinkerOS still has issues. It does work well as far as being able to switch between connections using nmcli. I'm not having to reboot to get connected. However, after just sitting for some time;  in the X windows env, I get a popup 'Authentication required' -- the password is filled in so I have to hit 'Connect' and then it's back online. If that is the only issue with that then I may be able to reconnect using a script I guess.

I'm also wondering though; based on the answer above; could I or should fall back to an earlier version of Armbian so that I have the older kernel with the new driver?

BTW; when I look at cat /sys/class/net/wlan0/operstate I get 'dormant'  when it's down and I'm seeing the prompt for a password. (again, this is in TinkerOS) 

I coded into my application to check the status every few minutes and if it's and ethernet is also down it restarts network-manager service and that seems to work. After 3 tries if it's still down; it reboots the unit. (I would like for the network-restart to work - but most of the time it doesn't and the dropout is way more frequent.) I found an interesting thread here https://tinkerboarding.co.uk/forum/thread-566-page-3.html

but did not really get anything useful from it.

[zeekoe]

Hi all,

 

For some time I've been following development. I think of buying a Tinker board. My wishes:

- Being able to act as a web server (e.g. Apache/PHP) + do some scripting

- Use the GPIO's (root mode no problem)

- Decent audio out (no audiophile quality needed, but RPi is too bad for my purpose)

- Long term software support that's as open as possible

 

Especially the latest reason is where my doubts are. Of course no guarantees can be made, but what would be the odds of Armbian (or a fork) supporting this board in, say, 5 years? I don't really trust ASUS' OS for this. Spending some time to configure stuff (like the audio now, as I understand) is no problem for me. What do you guys think?

 

Thx!

[TonyMac32]

12 hours ago, zeekoe said:

Long term software support that's as open as possible

I have no intentions of letting the board die, and it is supported well in mainline.  I don't see Armbian going anywhere in the meantime.

 

Audio should "just work", but I admit I haven't checked in a while, and kernels have been changed.  Worst case you should just have to select the proper output in PA.

[zeekoe]

Well supported in mainline, that's what I like to hear, thanks.

As for audio, does that also mean the 3.5mm jack? It surprises me reading the other thread about audio.

I might take the plunge, this board deserves a broader user base.

[TonyMac32]

The 3.5 is just a USB device directly soldered to the board, so yes, that's the one that took some adjustment. There have been some reports of I2S through HDMI not working properly lately, I need to review

Sent from my Pixel using Tapatalk

[AuerE]

Another wish would be the ability to use either UART4 or SPI0. On the (rather old) TinkerOS kernel, it is possible to edit a small configuration file to disable UART4 and enable SPI0 and vice versa, as both share pins on the GPIO header. I have yet to find out how to do the equivalent in the (rather modern) Armbian Stretch Next kernel. See also the separate thread about my attempts in using both SPI0 and SPI2 at the same time.

 

 

[TonyMac32]

Tinker S eMMC iozone:

 

	Command line used: iozone -e -I -a -s 100M -r 4k -r 16k -r 512k -r 1024k -r 16384k -i 0 -i 1 -i 2
	Output is in kBytes/sec
	Time Resolution = 0.000001 seconds.
	Processor cache size set to 1024 kBytes.
	Processor cache line size set to 32 bytes.
	File stride size set to 17 * record size.
                                                              random    random                                         
              kB  reclen    write  rewrite    read    reread    read     write     
          102400       4    32212    37213    36771    36971    23893    36212                                                          
          102400      16    60315    61679    69904    70326    64224    58809                                                          
          102400     512    71918    72275   116044   116542   113055    71026                                                          
          102400    1024    72041    71703   118508   118489   116860    71708                                                          
          102400   16384    68241    72212   132131   132147   131849    72001