Desabilitar ttyS3 para debug

Labrador
#1

Ao iniciar os testes com a placa labrador verificamos a presença de apenas uma porta UART disponível para uso (ttyS0), porém para aplicação na empresa necessitamos de mais uma porta UART disponível.
Verificamos então que a ttyS3 estava sendo usada para debug do sistema, então vemos como solução desabilita-la para debug liberando o uso desses pinos em nosso projeto.

Por não ter domínio com a manipulação de kernels gostaria de receber uma ajuda
Versão da imagem: [kernel_3_image/] (http://downloads.caninosloucos.org.br/kernel_3_image/)
publicada em 11-Feb-2020 19:54
Versão da placa: Labrador Core V2.1 (32Bits)

#2

@engenharia_greenwave, Bom dia!

Primeiramente, poderia me esclarecer algo? existe algum motivo especifico para utilizar a versão com kernel 3?

Sobre a possibilidade de utilizar a uart ttyS3, é possível e relativamente simples, contudo perderá uma grande ferramenta para depuração.

Posso compilar uma versão do kernel com a ttyS3 ativada e lhe enviar por e-mail, mas seria bem mais simples em qualquer caso utilizando a versão do kernel 4 link

Att,

Igor Ruschi

1 Curtida
#3

Bom dia Igor, não existe motivo específico para utilização da versão com kernel 3, porém foi a imagem que conseguimos utilizar a UART 0 (ttyS0).

Não vejo motivo para não utilizar a versão com kernel 4, caso seja possível me enviar uma imagem tanto com a UART ttys0 ativada quanto a ttyS3 ficaria grato, pois lembrando que minha finalidade é ter duas UARTs habilitadas para uso

E-mail para contato: desenvolvimento@greenwave.ind.br ou engenharia@greenwave.ind.br

Att,

Ulisses Zorzan

#4

Ulisses,

Entendo, se não há razão especifica para utilizar o kernel 3, vou sugerir que realize a alteração para o kernel 4, portanto realize o procedimento descrito aqui. Isso tornará as coisas mais fáceis apesar de ser um procedimento demorado.

Vou sugerir que dependendo do projeto que esteja trabalhando aprender a realizar a troca do kernel, nosso kernel pode ser encontrado neste git, nele há um ‘README’, que ensina a compilar e transferir o kernel compilado para a placa. Caso tenha dúvidas poste no forum.

Vou lhe enviar uma versão compilada do kernel por e-mail, com as uarts habilitadas como deseja. Mas faça o procedimento descrito no início, caso contrário certamente terá problemas, isto é, deve realizar a instalação do sistema primeiro, depois realizar a troca do kernel para a versão que vou lhe enviar via e-mail.

Att,

Igor Ruschi

1 Curtida
#5

Irei realizar a troca do kernel seguindo os passos indicados, qualquer dúvida posto aqui no fórum novamente.

Agradeço pela ajuda e fico no aguardo do e-mail

E-mail para contato: desenvolvimento@greenwave.ind.br ou engenharia@greenwave.ind.br

Att,

Ulisses Zorzan

#6

@engenharia_greenwave

Lhe envie agora o kernel, fiz um teste simples utilizando o comando echo, parece estar tudo ok, caso tenha algum problema, poste novamente.

Att,

Igor Ruschi

1 Curtida
#8

Bom dia Igor,

Iniciei os procedimentos como mencionados acima, passei a utilizar uma imagem com kernel 4 como mencionado, porém como estou sem o recurso de um cabo serial para poder gravar a imagem então estou dando o BOOT pelo cartão SD através da edição da linha root=/dev/mmcblk2p2 por root=/dev/mmcblk0p2 .

Após seguir os procedimentos descritos no e-mail para troca do kernel, ao iniciar a placa e dar o comando “sudo dmesg |grep ttyS” passei a ter a seguinte resposta:

caninos
caninos.png1104×553 16.4 KB

Imagino que devo estar errando ou deixando de seguir algum procedimento, seria pelo fato de não estar gravando a imagem na placa e apenas dando o BOOT ?

Att,

Ulisses Zorzan

#9

@engenharia_greenwave, Bom dia!

O fato de realizar o procedimento pelo cartão(mmcblk0p2) ou memória interna(mmcblk2p2) não interfere, o boot segue da mesma maneira. Pelas informações que você passou me parece que as 3 seriais foram carregadas normalmente, a ttyS2 é utilizada para o bluetooth.

O comando echo apenas imprime no terminal o literal exposto a sua frente, para realizar um teste simples use;
$ echo “aaaaa” >> /dev/ttyS3 (desta forma você encaminha a saída do comando echo para o dispositivo de uart)

No meu caso disponho de um osciloscópio para verificar o sinal, mas você pode realizar o teste na própria labrador, pode realizar um loopback entre ttyS3 e ttyS0 (tx de um no rx do outro). Escreva um programa em c ou na linguagem que preferir, use alguma api para acessar as seriais, use um ttySx para enviar e a outra para receber. Na verdade serão 2 programas. (neste link, já há disponível os dois programas prontos, basta baixar alterar a uart a ser utilizada, compilar e executar como sudo.)

Para verificar ou alterar o status da uart, como baudrate entre outras, utilize o comando ‘stty’
$ sudo stty -F /dev/ttyS3 -a ( mostra todas as configurações amarradas a estrutura do sistema)
$ sudo stty -F /dev/ttyS3 115200 (ialtera o baudrate desta uart para 115200bps)

*obs: se estiver sem um serial para transferir para a placa, você pode clocar o as unidades do cartão para as unidades da memoria interna, use comando ‘dd’ (é necessário desmontar as unidades mmcblk2p2 e mmcblk2p1 antes de usar o dd), procedimento feito na labrador abaixo;
** $ sudo dd if=/dev/mmcblk0p1 of=/dev/mmcblk2p1 status=progress
** $ sudo dd if=/dev/mmcblk0p2 of=/dev/mmcblk2p2 status=progress
monte as unidades novamente;
*** lembre de modificar o uEnv.txt dentro da unidade “BOOT” (mmcblk2p1), altere o parâmetro ‘root’ para ‘/dev/mmcblk2p2’, confira as unidades e pontos de montagem com o comando ‘lsblk’.

att,

Igor Ruschi

#10

Estou instalando todos pacotes necessários e compilando o java da minha aplicação para poder testar ambas seriais, mas minha dúvida maior seria sobre esse parâmetro “[ 0.416045] console [ttyS3] enabled”, este ainda me diz que a porta ttyS3 está sendo usada para o tráfego de dados de debug não é ? e eu preciso que não haja esse tráfego, somente que os meus dados trafeguem nessa porta

att,

Ulisses Zorzan

#11

Desculpe, não percebi a o que você se referia, isso é estranho, supostamente removi todos os links da uart 3 com o console, vou fazer mais uma verificação, logo reporto aqui.

att,

Igor Ruschi

1 Curtida
#12

Agradeço pela atenção e pelo suporte,
Fico no aguardo de uma resposta!

att,
Ulisses Zorzan

#13

Encontrei o problema, mas a solução vai demorar um pouco, acredito que somente amanha.

O problema está um pouco antes da inicialização do kernel, no u-boot que fez a reserva do ttyS3 como console.

Por enquanto, mantenha no uEnv.txt os parâmetros, loglevel=0 e console=tty0, com isso somente se algum erro critico no sistema ocorrer algo será enviado pela serial, mas você ainda pode abrir o arquivo rsyslog.config em /etc/rsyslog.config e comentar a linha “.emerg :omusrmsg:” adicionando “#” no inicio da linha, com isso suponho que não haverá nada trafegando pela uart3 além do que você enviar.

Vou trabalhando em uma solução definitiva enquanto isso…

Att,

Igor Ruschi

1 Curtida
#14

Sem problemas, fico no aguardo !

Att,
Ulisses

#15

Boa tarde,

Apenas atualizando, realizei o procedimento sugerido acima porém mesmo assim se eu interligo minha serial na uart3 e inicio a Labrador a mesma trava e não chega a mostrar a tela de login (acompanhei o processo através do HDMI)

Obs: se eu interligo essa minha serial em outro embarcado funciona corretamente, estou mencionando esse fato apenas para ser descartado a possibilidade do problema ser da serial que estou gerando

Att,
Ulisses Zorzan

#16

@engenharia_greenwave,

Bom dia!

Consegui terminar os procedimentos necessários, gerei um novo u-boot, a uart3 será utilizada somente durante o bootloader.

Para atualizar o seu u-boot acesse esse git temporario.
Baixe o arquivo “u-boot-dtb.img”, para uma pasta na labrador, vamos supor “/home/caninos/Documents”

execute o comando “cd”, como abaixo, para mover para o diretório onde baixou o arquivo “u-boot-dtb.img”
$ cd /home/caninos/Documents

Execute então o comando abaixo;

$ sudo dd if=u-boot-dtb.img of=/dev/mmcblk2 bs=512 seek=66 status=progress

reinicie a placa

$ sudo reboot

Com isso ao iniciar, a labrador ativará a console exclusivamente pelo descrito no arquivo uEnv.txt no parâmetro “console” mantenha como “console=tty0” (isso envia para o monitor hdmi).

caninos@debian-armhf:~$ sudo dmesg | grep ttyS
[sudo] password for caninos:
[ 0.436004] b0124000.serial: ttyS2 at MMIO 0xb0124000 (irq = 14, base_baud = 55555) is a caninos-uart
[ 0.436018] device: ‘ttyS2’: device_add
[ 0.436098] PM: Adding info for No Bus:ttyS2
[ 0.436539] b0126000.serial: ttyS3 at MMIO 0xb0126000 (irq = 15, base_baud = 55555) is a caninos-uart
[ 0.436555] device: ‘ttyS3’: device_add
[ 0.436638] PM: Adding info for No Bus:ttyS3

Att,

Igor Ruschi

1 Curtida
#17

Boa tarde @ruschigo,

Muito obrigado pela atenção e pela ajuda, o processo funcionou perfeitamente e agora estamos conseguindo dar prosseguimento com os testes utilizando a labrador.

Não sei se devo criar uma outra postagem, caso seja melhor me alerte, mas parece que o bluetooth está atrapalhando os processos da minha aplicação, desativando manualmente parece melhorar os resultados da aplicação, como poderia desabilita-lo de forma que não inicie durante a inicialização? Já retirei o script localizado no init.d e não resolveu.

Att,
Ulisses Zorzan

#18

@engenharia_greenwave, Bom Dia!

Ótimo, vou colocar esse tópico sobre desabilitar ttyS3 na Wiki!

Bem sobre o bluetooth, ele é de fato inicializado pelo script ‘wifi_bt_start.sh’ que você citou em /etc/init.d, ele utiliza a ttyS2, mas vou precisar saber a versão da sua base-board, por que temos 2 dispositivos bluetooth.

Mas independente do modelo, pode fazer o seguinte teste;

$ sudo update-rc.d wifi_bt_start.sh disable
$ sudo update-rc.d wifi_bt_start.sh remove

Para ter certeza que o processo do bluetooth não foi inicializado, existe um log do bluetooth, remova ele antes de reiniciar a labrador,

$ sudo rm /lib/firmware/bluetooth/rtl8723bs/script.log

quando reiniciar a placa, use o comando ‘ls’ para checar se o arquivo foi gerado.

$ ls /lib/firmware/bluetooth/rtl8723bs

Se o arquivo script.log não existir, então de fato o processo do bluetooth não foi inicializado. Isso garante que nada deve estar ligado a UART2.

Você ainda pode remover os pacotes que são utilizados pelo Linux, para conectar com o blueooth, que são hcitools, hciattach, hciconfig, esses pacotes podem ser removidos ao remover o pacote bluez

$sudo apt-get remove bluez

Com isso nenhum processo relacionado ao bluetooth deve ser inicializado.

Att,

Igor Ruschi