0
Michael S

OPC3 serial questions on bionic or other

Recommended Posts

Hello there,

 

I tried to use on  OPC3 bionic the ttyS1 for communcation with a serial device and didn't get it to work.

ttyS3 works fine. Configuration is done for both.

 

But now I need to communicate with a second and possibly a third serial device.

So I hoped for updates. But now I can't find a download of the bionic version and i have to make decision how to go further on.
Does it make sense to switch to buster or stretch? 

Is bionic only temporarily or finally offline? Whats the reason?
Any idea when there is a chance to get a stable release. Possibly with 6 Months or surely not within 6 months. Which version is more likely to be stable within 6 months.

 

What happend to ttyS2?

 

Does UART1 correlate to ttyS1... etc. 
I enabled, just for testing, the Overlays for UART1, UART2,UART3, which disables the Ethernet interface.

After disabling UART2 Ethernet works fine again. Do they share memory or other resources? Could it be a bug or a feature?
 

Is there a chance to stop kernel messages on ttyS0 completely so this can be used to attach a device?

Sorry for the bunch of questions and many thanks in advance.



 

 

Share this post


Link to post
Share on other sites
5 hours ago, Michael S said:

But now I can't find a download

 

If you can't find desired image for download, you have to:

 

- make one: https://github.com/armbian/build

- send a PR with changes to this file https://github.com/armbian/build/blob/master/config/targets.conf and if your changes are approved, additional image will be build next time (2/2020 in this case)

- join as a volunteer and help people 

 

5 hours ago, Michael S said:

Does it make sense to switch to buster or stretch?

 

They are identical - (armbian) kernel is talking to hardware - from the hardware support perspective. Their difference is only in software packages versions and their relations, upper level, user space.

 

5 hours ago, Michael S said:

Any idea when there is a chance to get a stable release.


Stable release is the core, the expensive development and most difficult problem. Your contribution to Armbian effort to make things stable is below 0.5% - our day dealing with you & hw currently costs several thousands if I count time core group do on the project every day. We are not alone in this and there are also other groups and individuals which are mainly supporting R&D out from their pocket. Most of them doesn't deal with users since its even more expensive and resourceful. Until relations between your input and stability is so extreme, skip such questions. Support is as is.

 

5 hours ago, Michael S said:

Is there a chance to stop kernel messages on ttyS0 completely so this can be used to attach a device?

 

Possible, but its a complex problem and goes out of general usage. Perhaps hire some people if you need such customization and support things that already works smoothly for you / general development.

Share this post


Link to post
Share on other sites
6 hours ago, Michael S said:

I enabled, just for testing, the Overlays for UART1, UART2,UART3, which disables the Ethernet interface.

After disabling UART2 Ethernet works fine again. Do they share memory or other resources? Could it be a bug or a feature?

UART2 is sharing pins with GMAC, so, don't use UART2 overlay, anyway UART2 pins are not even available on the header ...

Share this post


Link to post
Share on other sites
12 minutes ago, Igor said:

@Michael S

In case you need lots of UART's consider getting Olimex Lime boards.

Thanks for the idea. Hadn't considered them until now. But they seem not to support wlan. But i will surely check them more deeply.

my complete spec is:

8gb emmc, sdcard, lan+wlan, 2 freely useable serial ports, enough Power+RAM for Linux+python+frameworks+webserver etc.


But we go a little off-topic, the Orange Pi 3 device works fine for me except for the ttyS1 which may or may not my fault.
Does it even possibly correlate to the bionic version? Other experiences?

 

Just to make clear. I'm new to the development on this side. I'm asking to get advice and to document problems to be found by others with similar issues. At the moment I'm not able to fix serial problems on the driver or kernel side. And if there could be build a meaningful package without experiance is the question...

 

So as i understood some of the answers: Theres not much difference between buster/stretch and bionic and no one is working on bionic so there will be no future version of it. Is this right? Are there any "official" (quoted by intention) statements regarding this? Who are the people working on the Orange Pi 3 support? Is there a list?

 

To get totally offtopic: What qualifies a package to be mentioned on the primary devices download page and what disqualifies them so they get removed. If i think longer on some of the answers it seems to me that i lack understanding of the armbian processes - but be nice to a beginner...


thanks to all repliers

Share this post


Link to post
Share on other sites
7 minutes ago, Michael S said:

But they seem not to support wlan.


Most of on-board wlan interfaces are basic. In case you need top performance, you have to seek for external (USB/mPCI) solution. There serious game in this area starts. But for average usage, on-board are just fine. Unless you choose some cheap entry model (Orangepi Zero).

 

9 minutes ago, Michael S said:

bionic


Once again. Ubuntu naming has no relation to hardware related functions. Ubuntu is reselling packages in a different combination than Debian and that's the primary reason why we provide both - this part is reasonable cheap. We use their user space (application level) in combination with our kernel. Kernel is the king. 

 

12 minutes ago, Michael S said:

Theres not much difference between buster/stretch and bionic


On hardware level, not a single one.

 

13 minutes ago, Michael S said:

Who are the people working on the Orange Pi 3 support? Is there a list?


There is no such list. By downloading/using free available software you are not becoming a client of Armbian. The best/only support you will get is here on this forum, for elsewhere I can't tell. There are companies that provide support for kernel development, but it won't be cheap.

 

14 minutes ago, Michael S said:

What qualifies a package to be mentioned on the primary devices download page and what disqualifies them so they get removed.


When device lost support status or they are not there, things are safe to be completely removed. Especially test nightly builds are just removed at some point. They were never meant for you to use them. Only for testing.

We take care of a kernel and on the download pages, there are just some of most interesting variants. For example: boards with lots of memory and HDMI output have desktop builds too, while smaller not so powerful board don't have desktop builds. Mainly we provide Bionic / Buster variants but in case boards is suitable for running OMV (Helios4 for example) ... we also provide Debian Stretch since Buster version is still broken (not Armbian problem) to some degree. If things differ from this it could also be due to a bug/problem/non-intentional but to fix anything a scarce human resource has to do something about. And thing can wait ... and wait. There are no dedicated support persons to deal with you since you don't support their existence.

Share this post


Link to post
Share on other sites
54 minutes ago, Michael S said:

2 freely useable serial ports

 

54 minutes ago, Michael S said:

except for the ttyS1

UART1 is used for bluetooth and not available on header. On header, on UART3 and S-UART are available.

But for S-UART, you can't load overlay using the usual way in /boot/armbianEnv.txt, otherwise, it will get priority over /dev/ttyS0 (UART0) and debug port.

You need to load it dynamically using some scripting in /etc/rc.local like :

mkdir /sys/kernel/config/device-tree/overlays/ruart
cat /boot/dtb/allwinner/overlay/sun50i-h6-ruart.dtbo > /sys/kernel/config/device-tree/overlays/ruart/dtbo 

Then, to figure out which port it became, do a "dmesg | grep tty" ,,,,

Share this post


Link to post
Share on other sites

Hello, sorry for the delayed response.

Were using the OrangePi3 for some reason: cheapness and features, i've bought a small bunch of them for developement purposes in China. 

Dear Igor my answer regarding the missing wlan meant the Olimex Lime boards. They seem to lack wlan. The orangepi3s not.

And regarding the buster, bionic etc. issue. We used the distributions delivered by Orange Pi in the first place. I tried first their debian server version which run into some heat issues, after that i red that there are debian issues with the Thermal mangement on the h6 (or h5) so i tried to avoid debian versions. The ubuntu versions worked but they totally lack configuration tools.  And the Leds during the bootup process behave different. the debians went green after successful bootup, the ubuntu stays red.
After some research i found armbian where i choosed the ubuntu version for the same reasons.

The led sequence is also important because we need to signalise the bootup und the successful communication with the two serial devices after bootup. Which is not a problem but i would prefer the ubuntu always-red-version until we take control and talk to the devices.
Thats are the reasons why i'm sticking to bionic.

 

 

 

Dear Martin Mayotte

this is the result  of  dmesg |grep tty after adding your suggested lines to rc.local on my OrangePi3
[    2.079931] printk: console [ttyS0] enabled
[    2.101376] 5000400.serial: ttyS1 at MMIO 0x5000400 (irq = 20, base_baud = 1500000) is a 16550A
[    3.015818] 5000c00.serial: ttyS3 at MMIO 0x5000c00 (irq = 21, base_baud = 1500000) is a 16550A
[   16.846519] 7080000.serial: ttyS2 at MMIO 0x7080000 (irq = 243, base_baud = 1500000) is a 16550A

 

it seems that the S-UART got ttyS2, could this change in future or is it sure that i will always be ttyS2 also on other devices . (if there are no changes in hardware of course)

Somebody told to me that a S-UART is also or mostly called USART and also RUART is this correct?
Or are there some minor differences? Googleing on this is extremely inefficent.

Because of some additional needed electronics its a little bit tricky just to put the interface to the other pins so i have one further question.

Is a S-Uart capable of behaving asyncronous as a normal uart or are there some limitations. I couldnt find documentation on S-UARTS.
I have to use it in the range of 9600 to 115200 bps on a normal serial connection.

Many thanks.

 

 

Share this post


Link to post
Share on other sites

ttyS numbers are assigned semi-randomly, unless you name them specifically in the "alias" section in DTS. So that's the problem here.

Share this post


Link to post
Share on other sites
5 hours ago, Michael S said:

After some research i found armbian where i choosed the ubuntu version for the same reasons.

 

Once again. Armbian Ubuntu X and/or Armbian Debian Y are identical in low level functions. They share identical ATF, boot loader and kernel.

 

5 hours ago, Michael S said:

We used the distributions delivered by Orange Pi in the first place.


Most if not all board makers "distributions" are notoriously low quality. Some are better, some worse but none is actually a distribution. More like a quick and dirty copy (SoC development kernel) & paste with something (Debian, Arch, Ubuntu, Android, Centos, Raspbian, ...). What we do here is slowly develop things from scratch and provide a real (clean Ubuntu/Debian based) Linux distribution with updates and option to remake from sources ... but with a modern, up to date, (much closer to official Linux) kernel. Not all features (which are in old SoC development kernel) are here and certain problems are still present. That's why things are labelled as testing / WIP. If you want to use our distribution (or any other "distribution") on this board in production environment, don't. You will need to wait or better, help.

 

5 hours ago, Michael S said:

Dear Igor my answer regarding the missing wlan meant the Olimex Lime boards. They seem to lack wlan. The orangepi3s not.

 

WLAN is missing, but everything works for some time and all most popular USB based are supported out of the box. On Orangepi3 (and most other more recent boards) you need to wait until things are ironed out and until board support become matured. This will certainly not happen in 2019, while Lime boards already runs stable for years.

Share this post


Link to post
Share on other sites
11 hours ago, Michael S said:

Because of some additional needed electronics its a little bit tricky just to put the interface to the other pins so i have one further question.

Is a S-Uart capable of behaving asyncronous as a normal uart or are there some limitations. I couldnt find documentation on S-UARTS.
I have to use it in the range of 9600 to 115200 bps on a normal serial connection.

There no need for addtionnal electtronics. There is no difference between UART and S-UART, the "S" prefix only mean there are connected to PL gpio bank.

Share this post


Link to post
Share on other sites
5 hours ago, Igor said:

WLAN is missing

WLAN is working fine on OPi3, it only requires manually overwriting of the firmware version of brcmfmac4356-sdio.bin, same way as I did for NanoPiM4v2.

Share this post


Link to post
Share on other sites
5 hours ago, martinayotte said:

WLAN is working fine on OPi3, it only requires manually overwriting of the firmware version of brcmfmac4356-sdio.bin, same way as I did for NanoPiM4v2.


OP was commenting about missing WLAN on Olimex boards as a critical missing component while ignoring the most important aspect: software support (maturity). I would say yet another misguided by hardware specs/numbers. Which sells, yes, but tells little if they don't work as advertised.

Share this post


Link to post
Share on other sites
23 hours ago, martinayotte said:

There no need for addtionnal electtronics. There is no difference between UART and S-UART, the "S" prefix only mean there are connected to PL gpio bank.

Sorry, but there is a need on the side of the serial sevice to be attached. For example, the serial devices operate at different voltages. But whats so special about the PL bank to distinguish it from the other banks? I know they are all 32 gpio cpupins/numbers wide and the L stand for the multiplier eleven.

What does the "S-" stand for?

Share this post


Link to post
Share on other sites
On 12/7/2019 at 8:42 AM, Igor said:

Once again. Armbian Ubuntu X and/or Armbian Debian Y are identical in low level functions. They share identical ATF, boot loader and kernel.

 

WLAN is missing, but everything works for some time and all most popular USB based are supported out of the box. On Orangepi3 (and most other more recent boards) you need to wait until things are ironed out and until board support become matured. This will certainly not happen in 2019, while Lime boards already runs stable for years.

 

I got your point on low-level function but ive shown you the difference in LEDstatus-boot handling on the vendor debian/ubuntu images. Which could be important in some way...
 

Regarding wlan the problem is: i've got a requirement on WLAN etc. . List see above. And the idea with the orangepi 3 seems reasonable in the first place, but this maybe an error. Now I know this OPi3 device is wip so i asked about the 6 months above. Now ive learned that the wip-status is not different per distribution but same for all. So if it leaves wip status the drivers and configuration are ok.

So how likely is it to leave wip in 6 months? How long does this usually take? How likely is that it never leaves wip?
 

 

Share this post


Link to post
Share on other sites
32 minutes ago, Michael S said:

But whats so special about the PL bank to distinguish it from the other banks?

Those GPIOs are not part of PinControler #1 (pinctrl@300b000) but part of PinControler #2 (pinctrl@7022000).

32 minutes ago, Michael S said:

What does the "S-" stand for?

I think, but I could be wrong, that "S-" means "secondary", again because they are part of PinControler #2, like the same for S-I2C and S-IR.

Share this post


Link to post
Share on other sites
On 12/2/2019 at 11:28 PM, martinayotte said:

 

But for S-UART, you can't load overlay using the usual way in /boot/armbianEnv.txt, otherwise, it will get priority over /dev/ttyS0 (UART0) and debug port.

 

That are hopefully my final questions on this topic.

What is the meaning of "get prioritiy over ttyS0 UART0"?
Will it be routed to the 3 pin header und UART0 disconnected?
Or what is meant? Just to fully understand...

Share this post


Link to post
Share on other sites
20 hours ago, Michael S said:

Or what is meant? Just to fully understand...

If the R-UART overlay is loaded using /boot/armbianEnv.txt, this uart will become the /dev/ttyS0 instead of debug port, which will then slip as /dev/ttyS1, but since kernel argument still pointing to ttyS0, the debug output will go into wrong port.

Share this post


Link to post
Share on other sites

Many thanx Martin Ayotte and Igor and all the others for your advice.

Except for the look into the crystal ball regarding the likelyhood of getting stable all seems as clear as possible to me.

The s-uart works as expected on ttyS2 and Olimex Lime Boards are now in our internal discussion possibly with an usb-wlan-module...

 

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
0