Linux: [Perguntas] Upstreaming do Raspberry Pi 4

@pelwell alguma ideia?

@ P33M escreveu / copiou os dts GIC.

1. A interrupção da manutenção é padrão, presumo. O GIC é um IP não modificado. Falta propriedade.
2. a afinidade de interrupção segue as definições de IRQ - a primeira célula corresponde a cpu0, a próxima cpu1 etc. Falta a propriedade. Além disso, devemos excluir o parâmetro compatível com PMU a53 e apenas deixar o parâmetro a72.
3. Eu acredito que a propriedade é necessária - os stubs de braço não fazem nenhuma configuração de temporizador, exceto para definir a frequência do contador e zerar CNTVOFF_EL2.
   https://github.com/raspberrypi/tools/blob/master/armstubs/armstub8.S

3a. A remoção da propriedade sempre ativa tem efeitos colaterais. Em um sistema ocioso com a propriedade removida, recebo 500 IRQs por segundo em vmstat com números iguais de interrupções de cronômetro de arco em todos os 4 núcleos. Com a propriedade adicionada, obtenho ~ 110 IRQs por segundo no vmstat com diferentes números de interrupções do temporizador. Parece que as CPUs não estão caindo em um estado ocioso sem tique-taque - o que teria implicações no consumo de energia.

Como uma primeira passagem, as correções para 1 e 2 também podem ser feitas a jusante:

https://github.com/raspberrypi/linux/pull/3104

Muito obrigado

Mais perguntas:

1. É correto que "brcm, bcm2835-system-timer" @ 7e003000 não está mais disponível para BCM2711?
2. A configuração do cronômetro foi concluída para ARMv7 e ARMv8?
3. A configuração do temporizador sobre a frequência de clk e CNTVOFF_EL2 é feita para todos os núcleos ARM?
4. É correto que os núcleos ARM nunca entram em nenhum modo de hibernação, o que desativa os comparadores de cronômetro?

Desculpe, por ser chato, mas faltam apenas alguns dias para as minhas férias. Preciso das respostas antes de enviar a próxima versão da minha série de patches.

O registro do temporizador do sistema em 0x7e003000 ainda existe e é usado pelo firmware, acho que é do lado 0xfe003000 ARM. Start.elf e o bootloader o inicializam para rodar a 1 MHz do OSC no início do dia.
Não sei o suficiente sobre a configuração do lado do ARM para comentar sobre os modos de hibernação ou CNTVOFF_EL2

Ok, isso responde à pergunta 1 e torna o movimento de timer @ 7e003000 para bcm2835-common.dtsi errado.

Em relação ao armstub7.S, não consegui encontrar algo relacionado à configuração do cronômetro, então presumo que isso seja feito apenas no armstub8.S

@ timg236 Como agora temos um GIC, seria necessário definir as 4 interrupções de acordo.

É possível publicar essas definições?

@pelwell @ P33M É possível obter as interrupções GIC para o temporizador do sistema BCM2711?

Você deve ser capaz de resolver isso por inter / extrapolação dos outros.

Ok, vou fazer o seguinte:

interrupts = <GIC_SPI 64 IRQ_TYPE_LEVEL_HIGH>,
             <GIC_SPI 65 IRQ_TYPE_LEVEL_HIGH>,
             <GIC_SPI 66 IRQ_TYPE_LEVEL_HIGH>,
             <GIC_SPI 67 IRQ_TYPE_LEVEL_HIGH>;

Sim - parece correto.

Obrigado

Em relação ao upstreaming, há mais perguntas:
1) Os relógios genet (chamados genet125 e genet250 em vcgencmd) são acessíveis para bcm2835-cprman? Qual é o seu registro ctl e div? Como está o tcnt_mux?
2) Há uma interrupção conectada ao Ethernet PHY?
3) Qual é o alcance do registro do bloco térmico?

1. Os relógios Genet são de divisores cprman genéricos.

CM_GENET_125CTL = 0x7e101210
CM_GENET_125DIV = 0x7e101214
CM_GENET_250CTL = 0x7e1011e8
CM_GENET_250DIV = 0x7e1011ec

tcntmux tem genet_250 como 45, genet_125 como 50.

1. Não :( polling MDIO é usado para o estado do link.
2. DTS tem os registros térmicos em:

        thermal: thermal<strong i="15">@7d5d2200</strong> {
            compatible = "brcm,avs-tmon-bcm2838";
            reg = <0x7d5d2200 0x2c>;
            interrupts = <GIC_SPI 137 IRQ_TYPE_LEVEL_HIGH>;
            interrupt-names = "tmon";
            clocks = <&clocks BCM2835_CLOCK_TSENS>;
            #thermal-sensor-cells = <0>;
            status = "okay";
        };

?
Ou você está perguntando sobre as larguras de bits do campo de leitura?

De acordo com o ponto 3: o problema é que eu sugeri que a faixa de registro no arquivo DTS vem de mim e partindo do pressuposto de que o BCM2711 tem um bloco AVS TMON. AFAIR o intervalo de registro original era 4. De acordo com a definição de bits, o BCM2711 parece não ser compatível com nenhum driver térmico bcm existente. Portanto, gostaria de usar o intervalo de registro real com base no hardware. Pelo menos a leitura do registro indica um intervalo maior do que 4.

O registro de temperatura usado é, na verdade, parte do AVS_RO e não do AVS_TMON. O bloco tem uma grande quantidade de registros relacionados aos osciladores de anel / monitoramento da tensão do núcleo, mas o único relacionado à temperatura está em 0x7d5d2200.

Parece que há um bloco AVS_TMON em 0x7d5d1500 com registros de viagens / interrupção nos lugares certos - o que acontece se você apontar o driver brcmstb_thermal para esse endereço?

Obrigado, vou tentar.

Infelizmente, isso não funciona. O driver brcmstb_thermal reclama sobre leituras inválidas. Uma tentativa de ler os registros via / dev / mem result em 0xfd5d1500 resulta em falhas de kernel.

@ P33M Isso está correto?

       /* GENET clocks (only available for BCM2711) */
       [BCM2711_CLOCK_GENET250]        = REGISTER_PER_CLK(
               SOC_BCM2711,
               .name = "genet250",
               .ctl_reg = CM_GENET250CTL,
               .div_reg = CM_GENET250DIV,
               .int_bits = 4,
               .frac_bits = 8,
               .tcnt_mux = 45),

A documentação refere-se a larguras de divisores fracionários e inteiros de 4 bits, então eu diria que sim.

Obrigado

Mais algumas perguntas:

1. De acordo com a ligação bcmgenet, há uma terceira interrupção opcional para Wake-on-LAN. Caso esteja disponível no BCM2711, qual é o número da interrupção?
2. A seguinte suposição está correta: BCM2711_CLOCK_GENET250 = relógio de operação normal, BCM2711_CLOCK_GENET125 = Relógio Wake-on-LAN?
3. Há uma incompatibilidade em bcm2838.dtsi no ethernet phy entre genet-phy @ 0 e o valor reg 0x1.
   Presumo que o valor reg é o correto.
4. Quem fornece o endereço MAC para o driver genet?
5. Qual relógio BCM2711 posso passar como relógio EEE para o driver genet?

Editar:
Respostas:

1. BCM2711_CLOCK_GENET125 é o relógio ref para RGMII. Não tenho certeza de qual relógio é adequado para Wake-on-LAN. Infelizmente, precisamos fornecê-lo, mesmo não usando Wake-on-LAN.
2. valor reg 0x1 está correto
3. O bootloader usa alias ethernet0
4. De acordo com o driver o clock deve ser de 27 MHz.

Enviei a V3 do suporte inicial RPi 4 hoje e há pelo menos uma solicitação de comentários.

bcm2711.dtsi

soc {
        ranges = <0x7e000000  0x0 0xfe000000  0x01800000>,
             <0x7c000000  0x0 0xfc000000  0x02000000>,
             <0x40000000  0x0 0xff800000  0x00800000>;

Pode ser bom receber alguns comentários sobre

@pelwell gentle ping

Muitas coisas podem ser boas, mas são necessárias? É tão bem documentado quanto todos os outros chips:

    soc {
        ranges = <0x7e000000 0x3f000000 0x1000000>,
             <0x40000000 0x40000000 0x00001000>;
        dma-ranges = <0xc0000000 0x00000000 0x3f000000>;

etc.

Experimente isto:

        ranges = <0x7e000000  0x0 0xfe000000  0x01800000>,  // Common BCM283x peripherals
             <0x7c000000  0x0 0xfc000000  0x02000000>,  // BCM2838-specific peripherals
             <0x40000000  0x0 0xff800000  0x00800000>;  // ARM-local peripherals

Mais algumas perguntas:

1. According to the bcmgenet binding there is a optional third interrupt for Wake-on-LAN. In case this is available on BCM2711, what is the interrupt number?

2. Is the following assumption correct: BCM2711_CLOCK_GENET250 = normal operation clock, BCM2711_CLOCK_GENET125 = Wake-on-LAN clock?

3. There is a mismatch in bcm2838.dtsi at the ethernet phy between genet-phy<strong i="7">@0</strong> and the reg value 0x1.
   I assume reg value is the correct one.

4. Who provides the MAC address for the genet driver?

5. Which BCM2711 clock can i pass as EEE clock to the genet driver?

@ P33M ping suave

Wake on LAN não funcionará no modelo Pi4 porque a interrupção do phy não está conectada.

O endereço MAC vem do OTP e é passado via linha de comando e: ou árvore de dispositivos.

Outros podem ter que comentar sobre o relógio EEE ou 125 MHz.

@ timg236 Obrigado pela sua resposta rápida. Preciso definir duas coisas distintas, o BCM2711 e o Raspberry Pi 4. Como a ligação do genet fornece 3 interrupções, presumi que a terceira estava disponível no SoC / GIC400, porque a interrupção PHY é definida no nó PHY.

Agora que o RPi 4 DTS inicial foi aplicado, estamos trabalhando no suporte a LAN. Portanto, qualquer ajuda sobre a atribuição do relógio é apreciada.

Eu estava perguntando sobre o endereço MAC, porque notei que a passagem via DT não funcionou com a versão limpa do nó genet .

Não estou surpreso que não esteja funcionando - o que aconteceu com os aliases? Você deve ter um alias chamado ethernet0 referindo-se ao nó MAC para a interface primária. Este é um padrão Linux padrão e é o que o firmware usa para localizar onde escrever o endereço MAC.

Desculpe, minha culpa. Obrigado por apontar.

Durante a conversa com Florian, ele disse que o modo phy fornecido pelo rpi4 dts não parece corresponder ao hardware.

Todas as opções possíveis da ligação YAML :

Atrasos RX e TX são adicionados pelo MAC quando necessário:

• rgmii

RGMII com atrasos RX e TX internos fornecidos pelo PHY, o MAC não deve adicionar os atrasos RX ou TX neste caso:

• rgmii-id

RGMII com retardo RX interno fornecido pelo PHY, o MAC não deve adicionar um retardo RX neste caso:

• rgmii-rxid

RGMII com atraso de TX interno fornecido pelo PHY, o MAC não deve adicionar um atraso de TX neste caso:

• rgmii-txid

De acordo com a explicação de Florian, 360c8e98883f9cd075564be8a7fc25ac0785dee4 é apenas uma solução alternativa para evitar chamar bcm54xx_config_clock_delay e preservar os atrasos padrão.

Descarreguei os seguintes valores de registro antes de bcm54xx_config_clock_delay tentar alterar os valores:
SHDWSEL_MISC: 0x71E7
SHD_CLK_CTL: 0x0100

Com base nessas configurações, o modo PHY seria: rgmii-rxid

Não tenho certeza se isso está correto.

A melhor abordagem seria adicionar suporte ao modo phy para os tipos ausentes (rgmii-id & rgmii-rxid) ao driver GENET e configurar o modo correto por meio do dispositivo.

Seria bom obter uma confirmação sobre o modo PHY correto.

Não estou muito familiarizado com o driver genet do Linux bcm mas verifiquei o firmware (*) e ele não faz nenhuma configuração do GENET ou do PHY. O 0x0100 para CLK_CTL se alinha com o valor padrão na folha de dados.

• A inicialização da rede do carregador de inicialização também não configura o CLK_CTL. Se a inicialização da rede foi usada, a configuração do MAC DMA é interrompida e limpa antes de iniciar o Linux, mas isso é tudo.

Eu tenho uma pergunta em relação ao bloco oscilador de anel que surgiu durante a captação térmica :

Qual é o deslocamento de registro e o tamanho em hexadecimal do bloco oscilador em anel (AVS RO)?

AVS_RO_REGISTERS_0: 0x7d5d2200-0x7d5d22e3

Isso também me parece estranho, pois todos os outros blocos estão alinhados a 0x1000. O que está em 0x7d5d2000?

Há um bloco de nível superior que contém vários sub-blocos (AVS_RO_REGISTERS_0 é um).
AVS_MONITOR 0x7d5d2000 - 0x7d5d2eff

Como o suporte a pcie chegará em breve, agora o foco está no suporte a USB. O commit b9b1e6f49e64fa1cd4807f07bb8e9c70f896de0a não tem explicação.

Por que essa peculiaridade é a maneira certa de obter suporte LPM?
Qual é a fonte que diz que VIA VL805 suporta LPM?

Por que essa peculiaridade é a maneira certa de obter suporte LPM?

Você conhece uma maneira melhor?

Qual é a fonte que diz que VIA VL805 suporta LPM?

A documentação que temos da VIA, e observação do ônibus mostrando ele entrando nos estados LP.

Não sou contra a mudança funcional, mas precisamos de uma boa explicação no log de commit. O fato de precisarmos usar uma peculiaridade me faz pensar que há algum tipo de problema com o VL805. Não sei nada sobre PCIe, mas parece que o anúncio LPM deste chip não foi implementado corretamente.

@ P33M Essa peculiaridade era necessária porque os recursos PCIe tinham 0us para RestoreTime e PowerOnTime? Em caso afirmativo, essa peculiaridade não é mais necessária se estiver executando o firmware 0137ab atual?

Acho que foi porque as latências de saída do U1 / U2 eram 0us. Com 0137ab, vejo que eles estão definidos para 4 e 231us, respectivamente. Revertendo para teste ...

Sim - sudo lsusb -v | & grep ExitLat mostra valores diferentes de zero para mim.

Ah. Com a confirmação revertida, o descritor do hub raiz não tem as latências de saída preenchidas. Ele requer a configuração do quirk para xhci_create_usb3_bos_desc () para preencher os campos dos parâmetros HC, então o LPM é desabilitado por padrão em todos os controladores de host que não correspondem à grande tabela em xhci-pci.c: xhci-pci-quirks () .

Ok, com base na última resposta, considero o commit b9b1e6f49e64fa1cd4807f07bb8e9c70f896de0a como candidato a upstreaming.

Novas perguntas sobre GPIO:

1. Quais GPIOs do BCM2711 estão conectados ao SPI Flash?
2. Os sinais HDMI0_HPD_N e HDMI1_HPD_N são GPIOs do BCM2711?
3. Os GPIOs BCM2711 a seguir estão conectados a uma função específica?
4. GPIO27, GPIO28, GPIO29, GPIO46, GPIO47, GPIO48, GPIO49, GPIO50, GPIO51, GPIO52, GPIO53

ping suave @pelwell

1. GPIOs 40-43 são MISO, MOSI, CLK e CE_N. No entanto, 40 e 41 são compartilhados com o PWM de áudio, portanto, não acesse o flash com o amplificador de áudio habilitado. Seria melhor tratar isso como uma ROM que o firmware pode atualizar.
2. Sim - BCM2711 tem pinos HTPLG dedicados para HDMI0 e HDMI1.
   3
   GPIO27 está no cabeçalho de 40 pinos, então não.
   GPIO28 e 39 conduzem a interface Ethernet PHY MDIO, ou seja, rgmii_mdio_gpio28 (relatórios raspi-gpio RGMII_MDIO e RGMIO_MDC).
   GPIO46-51 são RGMII_RX e GPIO52-57 são RGMII_TX. Eles são trocados por um bit mux de pino de nível superior definido pelo firmware, daí porque raspi-gpio não vê nada.

Obrigado. Ups, não sabia que o BCM2711 suporta mais GPIOs.

Portanto, há mais perguntas (esperando que você tenha permissão para responder):

1. Quais são os intervalos de registro para GPIO54-57 (BCM2711)?
2. Quais são os nomes de sinais exatos (por exemplo, RGMII_RXD0 ...) para GPIO46-57?

Quais são os intervalos de registro para GPIO54-57 (BCM2711)?

O mesmo - eles preenchem alguns dos bits não utilizados nos registros BCM2835, com os deslocamentos óbvios.

Quais são os nomes de sinais exatos (por exemplo, RGMII_RXD0 ...) para GPIO46-57?

46: RGMII_RXCLK
47: RGMII_RXCTL
48: RGMII_RXD0
49: RGMII_RXD1
50: RGMII_RXD2
51: RGMII_RXD3

52: RGMII_TXCLK
53: RGMII_TXCTL
54: RGMII_TXD0
55: RGMII_TXD1
56: RGMII_TXD2
57: RGMII_TXD3

Aguentar. GPIO48 – GPIO53 foi usado anteriormente para acessar o leitor de cartão microSD integrado (usando AltFn 0 para SD0_xxx). Se esses GPIOs agora são usados ​​para RGMII, onde está o EMMC agora?

O Raspberry Pi 4 possui 3 interfaces de cartão SD (sdhost, sdhci e emmc2). O novo emmc2 que é usado atualmente para cartões SD é conectado fisicamente e não pode ser acessado via GPIO.

Ah, certo, isso está configurado pelo novo registro GPIO não documentado em 0x7e2000d0 ... Mas eu nunca pensei que também houvesse pinos dedicados para o cartão SD agora. De qualquer forma, acredito que também seja possível mapear a interface sdhci para esses pinos usando o registro mencionado acima. Deixe-me experimentar algumas coisas com esse registrador.

Editar: Sim, parece que o registro em 0x7e2000d0 (posso chamá-lo provisoriamente de GP_SDCARD até sabermos o nome oficial?) Controla como esses pinos de cartão SD dedicados são roteados:

• bit 0: conecte os pinos à interface Arasan MMC se configurada
• bit 1: conecte os pinos à nova interface EMMC2 se configurada

Ok, mas isso não significa que o EMMC2 está conectado ao GPIO48-53.

Não, certamente não.

FTR, o firmware imprime +DEDICATED_SD_PINS na inicialização para indicar esse recurso.

Tenho uma pergunta sobre o uso de I²C para PMIC on-board (XR77004). O firmare em um RPi4 imprime +PMIC_XR77004 e +SMPS_I2C . RPi 3B e RPi 3B + também tinham +PMIC_XR77004 , mas então +SMPS_GPIO .

A configuração do pino embutido diz o seguinte para RPi 3B +:

• / pins_3bplus / pin_defines / pin_define @ SMPS_SDA {type = "interno"; número = <46>}
• / pins_3bplus / pin_defines / pin_define @ SMPS_SCL {type = "interno"; número = <47>}

No RPi 4B, SMPS_SDA e SMPS_SCL são definidos como type="absent" . Isso faz algum sentido, já que o pino 46 agora é RGMII_RXCLK e o pino 47 agora é RGMII_RXCTL . Isso significa que também existem pinos dedicados para o barramento I²C com o PMIC? Em caso afirmativo, qual bloco I²C está anexado a ele?

Esquece. Ao rastrear os acessos ao registro de hardware na VPU, parece que há mais um bloco I²C (não documentado) em 0x7e205e00 e o firmware se comunica com um dispositivo com endereço 0x1d. Este endereço é usado pelo XR77004. Como o tráfego I²C não aparece em nenhum outro pino acessível, acho que é seguro presumir que o PMIC está em seus próprios pinos dedicados.

Tenho algumas perguntas sobre a série de patch KMS da Maxime (não quero me preocupar com a revisão desta série muito longa, então aqui):

1. O clock de 108 MHz é acessível por bcm2835-cprman?
2. O que é pai?
3. Como está o tcnt_mux?
4. O relógio pode funcionar como um portão?

108 é de PLLD PER, o que é lamentável, porque PLLD PER é na verdade 750 MHz, portanto, não é um divisor inteiro.

É um relógio CPRMAN CTL 0x7e101200 DIV 0x7e101204
tcnt 48 = clk_108

Tenho a sensação de que é necessário para o PCIe e deve ser tratado como um relógio sempre ligado