Linux: rpi-4.19-rt

Espero que sim. No momento, contamos com um voluntário - Tiejun Chen - para manter a filial, e outros compromissos significam que ele não teve tempo recentemente.

Os patches RT se aplicam de forma limpa ao branch 4.19.y Tem funcionado bem.

@ paul-1: Estou tentando aplicar o patch RT ao branch 4.19.y também.
Olhando para o conteúdo do patch TAR em , vejo que há uma lista de patches disponíveis:

0009-kthread-convert-worker-lock-to-raw-spinlock.patch
0012-arm-Convert-arm-boot_lock-to-raw.patch
0023-EXP-rcu-Revert-expedited-GP-parallelization-cleverne.patch
0028-sched-migrate_disable-Add-export_symbol_gpl-for-__mi.patch
0032-signal-Revert-ptrace-preempt-magic.patch
0036-rt-Provide-PREEMPT_RT_BASE-config-switch.patch
0052-x86-Use-generic-rwsem_spinlocks-on-rt.patch
0059-preempt-Provide-preempt_-_-no-rt-variants.patch
0061-rt-Add-local-irq-locks.patch
0066-buffer_head-Replace-bh_uptodate_lock-for-rt.patch
0067-fs-jbd-jbd2-Make-state-lock-and-journal-head-lock-rt.patch
0070-genirq-Disable-irqpoll-on-rt.patch
0076-mm-page_alloc-rt-friendly-per-cpu-pages.patch
0077-mm-swap-Convert-to-percpu-locked.patch
0098-time-hrtimer-avoid-schedule_work-with-interrupts-dis.patch
0099-hrtimer-consolidate-hrtimer_init-hrtimer_init_sleepe.patch
0100-hrtimers-Prepare-full-preemption.patch
0101-hrtimer-by-timers-by-default-into-the-softirq-contex.patch
0102-sched-fair-Make-the-hrtimers-non-hard-again.patch
0103-hrtimer-Move-schedule_work-call-to-helper-thread.patch
0104-hrtimer-move-state-change-before-hrtimer_cancel-in-d.patch
0105-posix-timers-Thread-posix-cpu-timers-on-rt.patch
0115-rt-Increase-decrease-the-nr-of-migratory-tasks-when-.patch
0128-rtmutex-trylock-is-okay-on-RT.patch
0130-rtmutex-Handle-the-various-new-futex-race-conditions.patch
0135-locking-locktorture-Do-NOT-include-rwlock.h-directly.patch
0136-rtmutex-Add-rtmutex_lock_killable.patch
0137-rtmutex-Make-lock_killable-work.patch
0139-rtmutex-Avoid-include-hell.patch
0141-rtmutex-Provide-rt_mutex_slowlock_locked.patch
0142-rtmutex-export-lockdep-less-version-of-rt_mutex-s-lo.patch
0143-rtmutex-add-sleeping-lock-implementation.patch
0144-rtmutex-add-mutex-implementation-based-on-rtmutex.patch
0145-rtmutex-add-rwsem-implementation-based-on-rtmutex.patch
0146-rtmutex-add-rwlock-implementation-based-on-rtmutex.patch
0147-rtmutex-rwlock-preserve-state-like-a-sleeping-lock.patch
0148-rtmutex-wire-up-RT-s-locking.patch
0149-rtmutex-add-ww_mutex-addon-for-mutex-rt.patch
0151-locking-rt-mutex-fix-deadlock-in-device-mapper-block.patch
0152-locking-rt-mutex-Flush-block-plug-on-__down_read.patch
0153-locking-rtmutex-re-init-the-wait_lock-in-rt_mutex_in.patch
0155-rtmutex-annotate-sleeping-lock-context.patch
0168-rt-Improve-the-serial-console-PASS_LIMIT.patch
0183-rt-Introduce-cpu_chill.patch
0184-hrtimer-Don-t-lose-state-in-cpu_chill.patch
0185-hrtimer-cpu_chill-save-task-state-in-saved_state.patch
0196-seqlock-Prevent-rt-starvation.patch
0197-sunrpc-Make-svc_xprt_do_enqueue-use-get_cpu_light.patch
0207-printk-Make-rt-aware.patch
0214-kgdb-serial-Short-term-workaround.patch
0216-mm-rt-kmap_atomic-scheduling.patch
0219-arm-Enable-highmem-for-rt.patch
0227-x86-stackprotector-Avoid-random-pool-on-rt.patch
0228-random-Make-it-work-on-rt.patch
0240-sched-Add-support-for-lazy-preemption.patch
0242-x86-Support-for-lazy-preemption.patch
0245-arm-Add-support-for-lazy-preemption.patch
0246-powerpc-Add-support-for-lazy-preemption.patch
0247-arch-arm64-Add-lazy-preempt-support.patch
0249-drivers-block-zram-Replace-bit-spinlocks-with-rtmute.patch
0254-drm-radeon-i915-Use-preempt_disable-enable_rt-where-.patch
0259-cpuset-Convert-callback_lock-to-raw_spinlock_t.patch
0262-signals-Allow-rt-tasks-to-cache-one-sigqueue-struct.patch
0264-Linux-4.19.37-rt19-REBASE.patch

Que conjunto de patches você aplica para obter um kernel RT estável no Pi?

https://mirrors.edge.kernel.org/pub/linux/kernel/projects/rt/4.19/patch-4.19.37-rt19.patch.gz

@antonellocaroli : Ótimo! Que outras opções, separadas de CONFIGURAÇÃO GERAL-> MODELO DE PREEMPÇÃO, você pode me recomendar que altere?
Em KERNEL FEATURES-> TIMER FREQUENCY, eu já tenho 1000Hz (padrão nos ramos 4.14.y e 4.19.y de qualquer maneira).

@vanfanel
você só precisa deles ...
mas dê uma olhada nisto para saber mais:
https://rt.wiki.kernel.org/index.php/Frequently_Asked_Questions

@antonellocaroli : Obrigado! Eu li esse documento há muito tempo.
O que geralmente faço para definir a prioridade em tempo real de um processo é:
1) Defina os limites de todo o sistema de acordo para que os usuários normais possam definir a prioridade em tempo real.
2) Execute o processo com chrt -f 80 <executable name>
Se você tiver qualquer outra observação a respeito de RT no GNU / Linux, por favor, compartilhe.

Seguindo, para que eu possa fazer com que o RealtimePi aponte para ele quando estiver pronto

+1

Acabei de perceber que ninguém realmente mencionou @TiejunChina . Portanto, não é à toa que isso está pendurado há 25 dias.

Tiejun está bem ciente da situação. Pingar nele (o que eu evitei intencionalmente) não vai ajudar.

@pelwell Entendido, isso não aconteceu aqui e não pude adivinhar sua comunicação privada. Desculpas.

Recomendo notificar isso da próxima vez, já que estava começando a especular sobre fazer meu próprio ramo de relações públicas.

Eu estava começando a especular sobre como fazer meu próprio ramo de relações públicas.

Eu não teria nenhum problema com isso, se você pudesse seguir o mesmo formato que o Tiejun fez. Os rpi-branches padrão usam commits de mesclagem para puxar patches de upstream para que eles mantenham seus IDs de commit, e commits de downstream de cereja / rebase para manter o histórico de commits claro - você acaba com dois fluxos paralelos de commits, "nós" e " eles".

Como escrevi para Tiejun na época:

"Uma de nossas regras internas é que, além de fazer o back-port de patches para kernels mais antigos, nunca mudamos os commits upstream. Isso significa que nosso desenvolvimento se parece com isto:

    L-L-L-L-L-L-L---L-L-L-L-L-L-L     = Upstream Linux
                 \       \       \
                  P-P-P-P-M-P-P---M-P = Downstream rpi- branch
                      ^   ^       ^
                      A   B       C

onde L é um commit upstream do Linux, P é um commit downstream Pi e M é um commit de mesclagem. A representa o ponto onde paramos de rebasear nossos commits contra a nova versão do kernel, o que corresponde ao ponto onde ele se torna nosso branch de linha principal. B e C são atualizações secundárias da versão do kernel.

"Talvez você possa estruturar o branch -rt assim:

    L-L-L-L-L-L-L----L-L-L-L-L-L-L     = Upstream Linux
                \         \       \
                 R-R-R-R-M-M--M----M-M = rpi-rt branch
                        /    /     /
                 P-P-P-P--P-P-----P    = Downstream rpi- branch

"Espero que você possa entender meu diagrama. O ponto importante é que os commits L e P neste diagrama são idênticos aos do anterior, com o mesmo hash de commit. A coisa boa sobre esse esquema é que, por não fazer o rebaseamento do seu commits, você só precisa trabalhar e pensar sobre (e consertar) novos commits. "

Se você puder seguir esse padrão e preparar um branch em seu repo, ficarei feliz em abençoá-lo e chamá-lo de rpi-4.19-rt. Se, ao fazer isso, você acabar criando qualquer ferramenta para simplificar a tarefa, diga-me - caso se torne fácil o suficiente, então, eventualmente, a tarefa pode ser implementada internamente.

Mesclar commits do Upstream Linux no branch RT é divertido. Eu nunca mantive uma cópia do git rt-kernel.

Ao fazer a manutenção para mim mesmo, quando há uma nova versão -rtxx, eu começo a partir de um branch rpi limpo e aplico o conjunto de patch rt, em seguida, seleciono todos os commits rpi-rt. Eu sei que alguns não gostam de rebasing constante, mas em minha mente mantém o branch rt apenas alguns commits diferentes do branch rpi normal.

@ paul-1 Pelo que entendi, você conseguiu fazer com que os patches RT funcionassem na versão 4.19. Eu tentei sozinho, mas tive problemas e espero que você possa ter algumas dicas.

Como o patch 4.19.y HEAD não funcionou, eu puxei o commit correspondente para 4.19.37. Estas são as etapas que tomei:

• git clone https://github.com/raspberrypi/linux.git --single-branch --branch rpi-4.19.y
• git checkout 19bb613acb9ad8e57593cad5118acaee117cc303
  (este é o commit mudando para a versão 4.19.37)
• make bcm2709_defconfig (teve que puxá-lo da cabeça, pois não faz parte do commit)
  Como os debos não são compilados, eu atualizei para o commit correto de rpi-update
• sudo rpi-update 6cf2788e74b497c109865d052cd6fa68d094cf38

Infelizmente, após a instalação do novo kernel, não consigo passar da tela do arco-íris. Alterar kernel7.img de volta para o original faz o sistema inicializar.

Eu não sou um especialista, mas olhando para a saída serial tty pode dar a você
mais informações sobre o que está falhando na tela do arco-íris.

O RPI está fazendo o rebase da árvore 4.19.y, você não pode voltar assim agora, a menos que vá e escolha todos os commits downstream do rpi. você tentou aplicar o 4.19.37-rt19 ao branch atual? Caso contrário, é melhor esperar até que o próximo patch rt seja lançado.

Ok, eu não sabia disso, mas explica porque as configurações estão faltando. Aplicar 4.19.37-rt19 ao branch atual não funciona, pois houve mudanças na linha principal que fazem com que a compilação falhe.

4.19.50-rt22 foi lançado, ele se aplica de forma limpa ao branch rpi atual.

Obrigado pela dica.

@ paul-1 O patch de correção dwc_otg também não é necessário?
https://www.osadl.org/Single-View.111+M5c03315dc57.0.html
Eu o tenho no controle de origem aqui:
https://github.com/guysoft/RealtimePi/blob/8b375fd1848276fa22c5c24a490d9696cd4a9e85/src/modules/realtimepi/filesystem/home/pi/patches/0001-usb-dwc_otg-fix-system-interrupup-interrupto. correção

Faz um tempo que não aplico isso e, definitivamente, não no branch 4.19, não percebi nenhum problema. Mas não fiz muitos testes pesados ​​de USB.

Edit: Você pode estar correto, acho que com todas as alterações do 4.19, cometi um erro no meu defconfig.

Por favor, dê uma olhada em https://github.com/pelwell/linux/tree/rpi-4.19.y.rt . É uma simples fusão do rpi-4.19.y.rt atual com os commits RT no topo. Também copiei um dos commits de Tiejun. Além de compilá-lo e inicializá-lo em um 3B +, não fiz nenhum teste real, mas se as pessoas acharem que está tudo bem, então estou feliz em colocá-lo como um branch semi-oficial com suporte de baixa prioridade do raspberrypi / linux.

Você deve alterar os defconfigs nesse branch para
CONFIG_PREEMPT_RT_FULL = y

Bom ponto. Eu atualizei o branch com defconfigs atualizados, mas sem a escolha certa do patch do Tiejun (estava travando para mim com isso incluído).

Também estou usando dtoverlay=dwc2 .

Vou tentar encontrar o tempo e fazer uma compilação ou RealtimePi, para que possamos todos ser
testando a mesma coisa.

Estou usando o driver dwc_otg padrão (com fiq e fsm habilitados) ... Nunca tive sorte com o dwc2.

Eu confirmei que o patch "não encadear irqs compartilhados" do Tiejun é necessário se o SPI estiver habilitado. Eu também apliquei o patch de osadl.org, mas houve mudanças no driver dwc_otg que ainda trava o sistema. Eu acredito que este commit adiciona um local que precisa ser bloqueado com fiq_fsm_spin_lock_irqsave 3ea9af8bc4eaac0cca72d603ed081973bce91bcf após corrigir essa parte, o kernel está estável ... mas fazendo mais testes agora.

Obrigado pelo feedback. Você provavelmente economizaria algum tempo e esforço se pudesse enviar uma Solicitação Pull com as alterações necessárias, caso contrário, tentarei novamente quando puder.

Farei isso assim que fizer algumas validações ... Não quero cometer erros que cometi com compilações RT anteriores.

Para que todos estejam atualizados, duas coisas aconteceram hoje cedo:

1. @ paul-1 enviou um PR (obrigado!) para o meu candidato RT branch: https://github.com/pelwell/linux/pull/1
2. @TiejunChina (bem-vindo de volta! (-8) criou um branch rpi-4.19.y-rt "oficial".

1) funciona para mim (sem a sobreposição dwc2), mas apenas se eu reverter o patch "no threaded irq".
2) também precisa ser revertido para mim, junto com um pequeno patch adicional para usar fiq_fsm_spin_lock_irqsave em dwc_otg_read_common_intr (isso está no conjunto de patches de paul-1).

Uma possível diferença entre a minha configuração e a sua é que eu uso o console UART em ttyS0 (o mini-UART com o IRQ compartilhado) - rodando com dtoverlay = pi3-disable-bt muda o console para ttyAMA0 / UART0 e evita o travamento. Uma reversão parcial - não encadeando a interrupção SPI, mas deixando a interrupção UART - também é eficaz, mas não estou usando SPI; mais testes são necessários.

Consegui uma construção noturna com o novo kernel:
Imagem:
* editar: a compilação noturna aqui não funcionou, veja a compilação mais recente *

Crie fontes de script para o branch rpi-4.19-rt:
https://github.com/guysoft/RealtimePi/tree/rpi-4.14.y-rt

@pelwell Você tem o patch ou link "no threaded irq" para confirmar, para que eu possa revertê-lo para a próxima compilação noturna?

Claro - é ca8809033b8f69f5999f3407f4f39667f07d7bee. Para ser claro, não estou dizendo que não precisamos de alguma variante desse commit, mas que não está correto como está.

Ok, vou reverter https://github.com/raspberrypi/linux/commit/ca8809033b8f69f5999f3407f4f39667f07d7bee e fazer outra compilação.

BTW, acabei de testar a compilação noturna sem ele. E o kernel entra em pânico na inicialização.
Parece que estou conseguindo isso:

e com kgdboc = ttyS0,115200 em cmdline.txt :

Ah, espere, https://github.com/raspberrypi/linux/commit/ca8809033b8f69f5999f3407f4f39667f07d7bee já está no rpi-4.19-rt, então foi enviado na imagem.

Ok, basicamente estamos presos por causa do kernel panic acima. Eu não sou um desenvolvedor de kernel, então se alguém quiser ajudar e me explicar o que está errado, e como consertar, isso pode ajudar a tornar o branch utilizável.

Também não sou um desenvolvedor de kernel, mas posso seguir o código e comparar quando as coisas quebram ...

O branch 4.19.y-rt no git raspberrypi / linux não funcionará como está se você tiver o FIQ habilitado. Se esse é o branch que você está usando,

Se o SPI estiver desabilitado, você pode reverter. https://github.com/raspberrypi/linux/commit/ca8809033b8f69f5999f3407f4f39667f07d7bee ]
Se o SPI estiver habilitado, você não pode reverter esse commit e não pode usar o console serial até que as coisas sejam resolvidas.

SE FIQ estiver ativado, você também precisará adicionar https://github.com/pelwell/linux/pull/1/commits/02586ccd069c7f0e7be7be4610a1207295ca9bc5

Como eu desabilitaria o FIQ?
Isso é uma boa ideia?
Estou tentando ter uma distribuição que você pode simplesmente piscar e usar este branch.
Acho que a maioria das pessoas usa com Jack2, então esse seria o meu foco. FIQ
efeito dispositivos USB?

Adicionar à linha de comando dwc_otg.fiq_enable=0 dwc_otg.fiq_fsm_enable=0.

Nos primeiros dias do single core, o usb estava quase inutilizável sem fiq ... não tenho certeza de como as placas mais novas funcionariam sem ele, muito menos um kernel RT. Mas como ainda é padrão para rpi usar fiq, deixo-o habilitado.

@ paul-1 Ok, adicionar dwc_otg.fiq_enable=0 dwc_otg.fiq_fsm_enable=0 o pendura em um local diferente agora.
Parece que ele está pendurado no driver da LAN. mas o kernel panic é o mesmo.

e com kgdboc = ttyS0,115200 em cmdline.txt:

Então isso meio que ficou quieto por causa do lançamento do RaspberryPi 4 - alguma opinião, o que está acontecendo de errado agora?

Há algum tempo, consegui fazer com que o 4.19.y funcionasse com o patch RT mais antigo. Tentarei pesquisar os parâmetros de configuração amanhã. A latência não tem sido ótima, mas funcionou de forma estável. Infelizmente meu PC de construção morreu, então tenho que pegá-lo no SD.

Esta é a linha de comando que uso para iniciar:
dwc_otg.lpm_enable=1 console=serial0,115200 console=tty1 root=PARTUUID=46877fa5-02 rootfstype=ext4 elevator=deadline fsck.repair=yes rootwait splash plymouth.ignore-serial-consoles
provavelmente apenas a primeira entrada realmente tem efeito.

Usei o patch rt20 no kernel 4.19.46 e tive que modificar um arquivo para compilá-lo. Tenho quase certeza de que o patch do usb-dwc_otg-fix foi corrigido.

Ok, usando @TheLongAndOnly faz o sistema inicializar! Mas sem USB funcionando. Testado em um RaspberryPi A +.

Eu tive que mudar:

dwc_otg.lpm_enable=0 console=serial0,115200 console=tty1 root=PARTUUID=c1dc39e5-02 rootfstype=ext4 elevator=deadline fsck.repair=yes rootwait quiet init=/usr/lib/raspi-config/init_resize.sh

Para:

dwc_otg.lpm_enable=1 console=serial0,115200 console=tty1 root=PARTUUID=c1dc39e5-02 rootfstype=ext4 elevator=deadline fsck.repair=yes rootwait splash plymouth.ignore-serial-consoles

Uname dá sobre ssh:

Linux realtimepi 4.19.50-rt22-v7 #2 SMP PREEMPT RT Thu Jun 20 07:50:16 BST 2019 armv7l GNU/Linux

Vou atualizar o cmdline.txt e fazer uma nova compilação.
No entanto, algo parece impossível.

Ok, tenho um noturno que botas, usando o galho. uname:

Linux realtimepi 4.19.50-rt22-v7 #2 SMP PREEMPT RT Sat Jun 29 10:17:23 BST 2019 armv7l GNU/Linux

O que não funcionou:

• teclado
• ethernet

o que funcionou:

• botas
• wi-fi e ssh
• 3B +
• 3A +

Baixe em:
http://unofficialpi.org/Distros/RealtimePi/nightly/2019-06-29_2019-06-20-realtimepi-buster-lite-0.4.0.zip
md5:
http://unofficialpi.org/Distros/RealtimePi/nightly/2019-06-29_2019-06-20-realtimepi-buster-lite-0.4.0.zip.md5

Binário:
http://unofficialpi.org/Distros/RealtimePi/nightly/2019-06-29_realtimepi-kernel-4.19.50.tar.gz

Também atualizado para buster.

Acho que precisamos adicionar usb-dwc_otg-fix para que o teclado funcione.

Não temos muito tempo para o diagnóstico no momento, mas ficarei feliz em fundir um PR para quaisquer alterações necessárias.

Também estou um pouco ocupado no momento, mas posso oferecer essas compilações do
branch para teste, uma vez que tenho a distro em vigor.

Alguém aqui está planejando brincar com ele?

Está um pouco fora da minha compreensão brincar com interrupções. O que tenho funciona para a nossa aplicação (piCorePlayer), pois a maioria dos nossos usuários não está interessado em usar a linha serial em um ambiente RT. Esse parece ser o grande criador do problema.

Agora, se eu pudesse colocar minhas mãos em minhas remessas de pi4, eu poderia começar a trabalhar.

Ok, tenho um noturno que botas, usando o galho. uname:

Linux realtimepi 4.19.50-rt22-v7 #2 SMP PREEMPT RT Sat Jun 29 10:17:23 BST 2019 armv7l GNU/Linux

O que não funcionou:

• teclado
• ethernet

o que funcionou:

• botas
• wi-fi e ssh
• 3B +
• 3A +

Baixe em:
http://unofficialpi.org/Distros/RealtimePi/nightly/2019-06-29_2019-06-20-realtimepi-buster-lite-0.4.0.zip
md5:
http://unofficialpi.org/Distros/RealtimePi/nightly/2019-06-29_2019-06-20-realtimepi-buster-lite-0.4.0.zip.md5

Binário:
http://unofficialpi.org/Distros/RealtimePi/nightly/2019-06-29_realtimepi-kernel-4.19.50.tar.gz

Também atualizado para buster.

Acho que precisamos adicionar usb-dwc_otg-fix para que o teclado funcione.

@guysoft Estou preso no meu trabalho normal, desculpe por este inconveniente. Você experimentou nosso rpi-4.14.-rt? Mesmo nós decidimos não atualizar isso, mas lembro-me de que 'teclado' e 'ethernet' funcionaram na minha placa 3b.

@TiejunChina Ei, que bom ver você de volta.
Sim, tenho um RC para isso:
https://github.com/guysoft/RealtimePi/issues/16

Precisamos, no entanto, mudar para rpi-4.19-rt .

@guysoft my rpi-4.14-rt pode funcionar muito bem no meu target.

pi @ raspberrypi : / boot $ cat cmdline.txt
dwc_otg.lpm_enable = 0 console = serial0,115200 console = tty1 root = PARTUUID = 7e31a93c-02 rootfstype = ext4 elevador = deadline fsck.repair = sim rootwait quiet splash plymouth.ignore-serial-consoles
pi @ raspberrypi : / boot $ cat config.txt
. # Para mais opções e informações, consulte
. # http://rpf.io/configtxt
. # Algumas configurações podem afetar a funcionalidade do dispositivo. Veja o link acima para detalhes

. # descomente se não obtiver nenhuma imagem no HDMI para um modo "seguro" padrão
. # hdmi_safe = 1

. # remova o comentário se sua tela tiver uma borda preta de pixels não usados ​​visíveis
. # e sua tela pode produzir sem overscan
. # disable_overscan = 1

. # descomente o seguinte para ajustar o overscan. Use números positivos se o console
. # sai da tela e fica negativo se houver muitas bordas
. # overscan_left = 16
. # overscan_right = 16
. # overscan_top = 16
. # overscan_bottom = 16

. # descomente para forçar um tamanho de console. Por padrão, será o tamanho da tela menos
. # overscan.
. # framebuffer_width = 1280
. # framebuffer_height = 720

. # retire o comentário se o display hdmi não for detectado e o composto estiver sendo reproduzido
. # hdmi_force_hotplug = 1

. # descomente para forçar um modo HDMI específico (isso forçará VGA)
. # hdmi_group = 1
. # hdmi_mode = 1

. # descomente para forçar um modo HDMI em vez de DVI. Isso pode fazer o áudio funcionar em
. # Modos DMT (monitor de computador)
. # hdmi_drive = 2

. # retire o comentário para aumentar o sinal para HDMI, se houver interferência, apagamento ou
.# nenhuma exibição
. # config_hdmi_boost = 4

. # descomente para PAL composto
. # sdtv_mode = 2

. # descomente para fazer o overclock do braço. 700 MHz é o padrão.
. # arm_freq = 800

. # Remova o comentário de alguns ou de todos para habilitar as interfaces de hardware opcionais
. # dtparam = i2c_arm = on
. # dtparam = i2s = on
. # dtparam = spi = on

. # Remova o comentário para habilitar o módulo lirc-rpi
. # dtoverlay = lirc-rpi

. # Sobreposições e parâmetros adicionais estão documentados / boot / overlays / README

. # Ativar áudio (carrega snd_bcm2835)
dtparam = audio = on
pi @ raspberrypi : / boot $ uname -a
Linux raspberrypi 4.14.91-rt49-v7 + # 32 SMP PREEMPT RT Seg 7 de janeiro 11:29:31 CST 2019 armv7l GNU / Linux

Vamos primeiro verificar se rpi-4.14.y-rt pode funcionar em seu destino.

@TiejunChen Sim , há um candidato a lançamento com rpi-4.14.y-rt .
https://github.com/guysoft/RealtimePi/issues/16

Ele inicializa e funciona.
Também recebi a confirmação de vários usuários.

O problema é com rpi-4.19-rt .

Obter mais relatórios - parece que funciona, mas apenas se você definir dwc_otg.lpm_enable=1 , o que eu acho que significa que precisamos de usb-dwc_otg-fix para fazer o patch.
Consulte: https://github.com/guysoft/RealtimePi/issues/13#issuecomment -510181947

Além disso, recebo relatórios de que este branch não está funcionando para RaspberryPi 4: https://github.com/guysoft/RealtimePi/issues/17

As instruções de construção mudaram?

@guysoft Acabei de encomendar um pi4 no mês passado, mas na China teremos de recebê-lo no próximo mês. Vou verificar isso assim que conseguir isso.

@TiejunChina Conheça bem aquela sensação quando você tem bugs abertos em sua base de código e nenhum acesso ao hardware.
Envie-nos um ping assim que conseguir. Sinta-se à vontade para pedir às pessoas do meu projeto que testem coisas, se isso ajudar (questão https://github.com/guysoft/RealtimePi/issues/17).

Também há relatórios interessantes aqui de pessoas testando coisas:
https://forum.linuxcnc.org/18-computer/36879-raspberry-pi-4?start=0#138874

@guysoft @pelwell @ paul-1 Acabei de atualizar rpi-4.19.y-rt como
4.19.59 + v4.19.59-rt23 + rpi-4.19.y patches contra 4.19.59 + "usb: dwc_otg: conserta o travamento do sistema quando as interrupções são encadeadas" + "Não é necessário usar _nort" + "Habilitar CONFIG_PREEMPT_RT_FULL". Eu também habilitei RT para bcm2711_defconfig.

Em processo de construção de uma nova imagem.
Será atualizado quando eu tiver uma imagem.
Devo também atualizar cmdline.txt para outra coisa?

Ok, obtendo um comportamento estranho.

Ele constrói e para no meio:

+ make ARCH=arm bcmrpi_defconfig
  HOSTCC  scripts/basic/fixdep
  HOSTCC  scripts/kconfig/conf.o
  YACC    scripts/kconfig/zconf.tab.c
  LEX     scripts/kconfig/zconf.lex.c
  HOSTCC  scripts/kconfig/zconf.tab.o
  HOSTLD  scripts/kconfig/conf
arch/arm/configs/bcmrpi_defconfig:32:warning: override: PREEMPT_RT_FULL changes choice state
#
# configuration written to .config
#
+ echo 'CONFIG_PREEMPT_RT_FULL=y
CONFIG_DEBUG_PREEMPT=n
CONFIG_PREEMPT_TRACER=n
CONFIG_RCU_CPU_STALL_TIMEOUT=21'
+ make -j4 zImage modules dtbs
scripts/kconfig/conf  --syncconfig Kconfig
.config:6391:warning: override: reassigning to symbol PREEMPT_RT_FULL
.config:6391:warning: override: PREEMPT_RT_FULL changes choice state
.config:6392:warning: override: reassigning to symbol DEBUG_PREEMPT
.config:6393:warning: override: reassigning to symbol PREEMPT_TRACER
.config:6394:warning: override: reassigning to symbol RCU_CPU_STALL_TIMEOUT
  SYSHDR  arch/arm/include/gen

[....]

  AR      drivers/char/ipmi/built-in.a
  AR      drivers/clk/actions/built-in.a
  CC [M]  net/ax25/ax25_uid.o
  CC      drivers/clk/bcm/clk-bcm2835.o
+ chmod 777 /mnt/sdc1/RealtimePi/src/build_dist /mnt/sdc1/RealtimePi/src/build.log /mnt/sdc1/RealtimePi/src/config /mnt/sdc1/RealtimePi/src/custompios_path /mnt/sdc1/RealtimePi/src/docker-compose.yml /mnt/sdc1/RealtimePi/src/image /mnt/sdc1/RealtimePi/src/image-variants /mnt/sdc1/RealtimePi/src/modules /mnt/sdc1/RealtimePi/src/vagrant /mnt/sdc1/RealtimePi/src/variants /mnt/sdc1/RealtimePi/src/workspace

Essa é a última linha, simplesmente não continua sem nenhuma mensagem.
Isso não aconteceu antes da atualização.

O que está montado em / mnt / sdc1? Você executou um fsck nele recentemente?

/dev/sdc1 é um disco rígido onde a imagem está sendo construída.
Desmontei-o e executei o fsck (foi montado 84 vezes sem ser verificado, verifique forçado. Então acho que é uma boa coisa a fazer de qualquer maneira).

Montando novamente e construindo, vai ver se há mudança, mas duvido porque falhou duas vezes no mesmo lugar.
Atualizará.

Como ele sempre falha no mesmo lugar, você pode tentar executar esse comando chmod sozinho. Também é possível que seja o próximo comando, aquele que não foi mostrado, que demore uma eternidade ...

@pelwell , ok, desmontar o ambiente docker e remontá-lo consertou. Estranho, mas corrigido :)

Imagem:
http://unofficialpi.org/Distros/RealtimePi/nightly/2019-08-07_2019-07-10-realtimepi-buster-lite-0.4.0.zip
md5:
http://unofficialpi.org/Distros/RealtimePi/nightly/2019-08-07_2019-07-10-realtimepi-buster-lite-0.4.0.zip.md5

kernel apenas que você pode descompactar em cima de um raspbian existente:
http://unofficialpi.org/Distros/RealtimePi/nightly/2019-08-07_realtimepi-kernel-4.19.59.tar.gz

Observação: não mudei o cmdline.txt mencionado aqui:
https://github.com/raspberrypi/linux/issues/2943#issuecomment -506561440
Provavelmente, agora que o patch usd owc está em vigor, posso removê-lo, reconstruí-lo e, com sorte, liberá-lo.

Os usuários estão relatando no RealtimePi que usb-dwc_otg-fix não ajuda, está mesclado na árvore?
Em caso afirmativo, pode ter havido alterações no driver USB agora que ele também usa o USB 3?

Você está falando sobre isso ?
https://github.com/raspberrypi/linux/commit/801df5aff559b438bbbc7c71180a85ec1b2f7124

@TiejunChina Sim, parece que o USB quando habilitado congela o sistema na inicialização. Houve uma grande mudança no kernel nesse aspecto, então eu acho que está lá, mas realmente deveríamos encontrar uma maneira de depurar o que está acontecendo lá.

E a depuração se torna um pouco complicada, pois todo o sistema congela. Existe alguma diferença na mudança, talvez as mudanças no kernel possam ser analisadas e as mudanças "correspondentes" no código de correção possam ser aplicadas (tipo de "correção cega")?

Pode ser que eu já tenha feito isso. Esta é a saída que obtive anteriormente:
https://github.com/raspberrypi/linux/issues/2943#issuecomment -504059617
usou kgdboc=ttyS0,115200 que fornece mais resultados na inicialização do kernel.

Pode valer a pena tentar adicionar isso na inicialização e ver se ainda estamos recebendo esse erro ou se é algo novo.

Existe alguma atualização sobre o progresso? Tenho tentado consertar isso também. Ou recebo o Kernel panic descrito acima ou o sistema inicializa sem Ethernet e USB ativos.

O status atual é que isso só funciona se você definir dwc_otg.lpm_enable=1 .
Isso significa que o patch atual para o driver USB não funciona com o novo kernel e precisa ser reescrito. Isso significa que alguém com conhecimento do que está acontecendo no kernel precisa intervir e escrever o código. Nenhum de nós está apenas usando patches de saída.

O patch original foi AFAIK foi publicado aqui . Por @oghorbel . Mas ainda não consegui contatá-lo para fornecer informações.

@TiejunChina Alguma notícia sobre isso? parece que há um PR que resolverá os travamentos de USB / FIQ

Obrigado @schnitzeltony não é trivial para mim o que você fez lá!

@schnitzeltony Estou construindo uma noite contra sua árvore, então temos algo para testar

Ei, a solução foi mesclada. E eu construí um candidato a lançamento com base no branch atual. Acho que vale a pena as pessoas aqui testarem. E também podemos esconder esse problema.

Deve funcionar em todos os Pis incluindo Rpi 4B (testei e funciona).
Baixe aqui: https://github.com/guysoft/RealtimePi/issues/20

Obrigado por seus esforços, Guy (dedos cruzados para um resultado bem-sucedido).

Deve funcionar em todos os Pis incluindo Rpi 4B (testei e funciona).

Funciona em 2 e 3?

Vinculação de problema relacionado - https://github.com/raspberrypi/linux/issues/3172

@gtrainavicius Deveria, CustomPiOS constrói tanto para 2 3 e até mesmo 1 e zero kernels. Eu testei em outra noite e funcionou.

@pelwell Existe um Release Candidate que testei e funciona no Pi4, e deve funcionar também em qualquer outro Pi, faltando apenas o kernel de 64 bits ( kernel8.img ). Você é bem-vindo para empurrar as pessoas para testar isso e confirmar. Acho que, se não tiver problemas, vou lançá-lo em uma semana ou mais.

onde encontro as fontes do kernel para compilar?

para aarch64, eu compilei as fontes aqui ...
https://github.com/raspberrypi/linux/tree/rpi-4.19.y-rt

e funciona, a única coisa estranha nisso é o uso da CPU.

uname -r 4.19.71-GentooPlayer-RT-MIN-rt24+

Este problema pode ser encerrado.
Além disso, você pode usar esta imagem se quiser, lançada :)
https://github.com/guysoft/RealtimePi/releases/tag/0.4.0

Obrigado novamente, Guy.

Obrigado

Você recebe um aviso e uma pilha de chamadas impressos ao executar o kernel RT no 3B +, como nos logs anexados neste comentário: https://github.com/raspberrypi/linux/issues/3172#issuecomment -569265745? RPi2 e 4 não parecem produzi-lo.