Linguagem Devicetree

Devicetrees usam o que é chamado de Domain Specific Language, então você precisa seguir as regras da linguagem quando estiver escrevendo um devicetree. Felizmente, é uma linguagem relativamente simples, e como seu uso é tão limitado, ela pode frequentemente ser aprendida apenas seguindo exemplos existentes.

Comentários

Comentários no devicetree são todos estilo de linha única. Eles usam o caractere '#' para começar o comentário e vão até o fim da linha.

Como estilizar

Coloque um espaço entre o sinal de cerquilha e o comentário.
- # Bom
- #Ruim
Fragmentos de frases são bons, mas não os termine com um ponto final.

Quando usar comentários

Existem locais padrão onde os comentários são normalmente usados e esperados.

Iniciando um grupo de configurações

Semelhante a comentar uma função com a intenção da função, pode ser útil descrever no topo de um bloco de configurações o que está sendo configurado. Abaixo está um bom exemplo.

# VR Settings Configuration for 4 Domains
# +----------------+-----------+-----------+-------------+----------+
# | Domain/Setting |         SA        |        IA         | GT Unsliced |        GT        |
# +----------------+-----------+-----------+-------------+----------+
# | Psi1Threshold  | 20A       | 20A       | 20A         | 20A      |
# | Psi2Threshold  | 4A        | 5A        | 5A          | 5A       |
# | Psi3Threshold  | 1A        | 1A        | 1A          | 1A       |
# | Psi3Enable     | 1         | 1         | 1           | 1        |
# | Psi4Enable     | 1         | 1         | 1           | 1        |
# | ImonSlope      | 0         | 0         | 0           | 0        |
# | ImonOffset     | 0         | 0         | 0           | 0        |
# | IccMax         | 7A        | 34A       | 35A         | 35A      |
# | VrVoltageLimit | 1.52V     | 1.52V     | 1.52V       | 1.52V        |
# | AC LoadLine    | 15 mOhm   | 5.7 mOhm  | 5.2 mOhm    | 5.2 mOhm |
# | DC LoadLine    | 14.3 mOhm | 4.83 mOhm | 4.2 mOhm    | 4.2 mOhm |
# +----------------+-----------+-----------+-------------+----------+

Fim dos blocos de palavras-chave

Se houver várias instruções end em uma linha, e não for imediatamente óbvio qual instrução end fecha qual bloco de palavra-chave, é útil adicionar um comentário para dizer o que está sendo encerrado. Abaixo, temos três instruções end em uma linha e o início desses blocos provavelmente está próximo ao topo do arquivo. Identificar o que a instrução 'end' está fechando pode ser determinado pelo espaçamento, mas ainda é útil anotá-lo com um comentário.

        end # agesa northbridge
    end # domain
end # northbridge/amd/agesa/family14/root_complex

Identificar o motivo de uma configuração

Registros que não têm um nome que torne óbvio o que está sendo definido, ou não têm uma macro que identifique o que está sendo definido devem ser comentados. A configuração do registro e a macro abaixo descrevem o que é a configuração, mas não descrevem para que estão sendo usados. Adicionar o comentário de “Câmera” dá ao leitor a informação extra para saber o que está naquela porta USB, e entender que você (geralmente) não precisa de proteção contra sobrecorrente para uma câmera.

register "usb2_ports[7]" = "USB2_PORT_MID(OC_SKIP)" # Camera

O registro abaixo tem um bom nome e informa que haverá um atraso de 12 ms, mas sem o comentário, você não sabe o porquê.

register "stop_delay_ms" = "12" # NIC needs time to quiesce

Dispositivos sem aliases

Era comum no passado comentar identificadores de dispositivos com o que o dispositivo é, mas isso pode ser menos necessário agora com aliases, que permitem que dispositivos sejam nomeados de forma significativa. Para plataformas mais antigas que não têm aliases definidos no arquivo chipset.cb, ou para dispositivos sem chipset, ainda é útil adicionar um comentário após o dispositivo ser definido.

Quando não usar comentários

Números mágicos

Isso se sobrepõe um pouco à próxima seção, mas se você precisar inserir um comentário para explicar o que está sendo definido, avalie se isso pode ser expresso como uma macro.

register "PmConfigSlpS3MinAssert" = "2"    # 50ms

Em vez de usar o número mágico 2, use uma macro, assim como seria esperado que você fizesse no seu código. Não é óbvio sem o comentário o que 2 significa, então use uma macro. Se houver algum motivo pelo qual uma macro não pode ser usada, então claro, adicione um comentário, mas isso deve ser bem incomum.

Comentários redundantes

Com uma boa nomenclatura, comentários podem não ser necessários. Exemplo de comentários redundantes:

register "ipc1" = "0x00000000" # IPC1

register "link_freq[0]" = "360 * MHz" # 360 MHz

Dispositivos com aliases

Para dispositivos com chipset ou SoC mais antigos, ou para dispositivos sem chipset que não tenham um arquivo chipset.cb, ainda é desejável usar comentários na linha 'device', mas se o dispositivo tiver um alias, ele deve ser usado.

Registros

Nomes de registro

Quaisquer registros que codifiquem um valor que tenha qualquer tipo de unidade devem incluir a unidade no nome em vez de em um comentário. O nome “tFAW” no registro abaixo é tirado diretamente do nome na especificação, mas adicionar as unidades torna muito mais fácil de entender.

register "tFAW" = "40000"                   # picoseconds

Use macros para valores codificados

Se o valor associado ao registro codificar a unidade, em vez de inserir o valor diretamente, adicione uma macro para o valor.

register "PchPmSlpS3MinAssert" = "3" # 50ms

Isso seria mais fácil de entender se tivesse uma macro, não apenas um número mágico, como visto abaixo.

register "PchPmSlpS3MinAssert" = "ASSERT_50_MILLISEC"

Palavras-chave do Devicetree

alias, como, chip, cpu, cpu_cluster, dispositivo, domínio, drq, fim, campo, fw_config, genérico, gpio, oculto, i2c, herdar, io, ioapic, ioapic_irq, lapic, obrigatório, mmio, desligado, ligado, opção, pci, pnp, sonda, ref, registrar, smbios_dev_info, smbios_slot_desc, spi, subsystemid, usb, usar

Tipos de palavras-chave

As palavras-chave são divididas em várias categorias diferentes. Algumas palavras-chave se enquadram em mais de uma dessas categorias.

Tipos de Alias

As palavras-chave do tipo alias são usadas para dar nomes legíveis aos dispositivos e, posteriormente, atualizar esse nome para um uso específico.

alias, como, usar

Recipientes

Essas palavras-chave agem para agrupar informações em unidades lógicas de diferentes tipos.

chip, dispositivo, domínio, campo, fw_config, fim

Tipos de dispositivos/barramentos

Essas palavras-chave são usadas para identificar o tipo de dispositivo que está sendo configurado e selecionar a estrutura apropriada para configuração.

cpu, cpu_cluster, domínio, genérico, gpio, i2c, ioapic, lapic, mmio, pci, pnp, ref, spi, usb

Modificadores de status de enumeração

Os modificadores de status determinam como um dispositivo deve ser tratado durante a enumeração.

ligado, desligado, oculto, obrigatório

Configuração de firmware

campo, fw_config, opção, sonda, ref

Alocação de recursos

drq, eu, irq

SMBIOS

smbios_dev_info, smbios_slot_desc

subsistema

herdar, subsistemaid

Registrar

registrar

MULTI-TABLE

ioapic_irq

Definições de palavras-chave

pseudônimo

Tipo de palavra-chave: Alias
Introduzido em junho de 2020, coreboot versão 4.12
Uso: device <device type> <device address> **alias** <ALIAS ID> <status modifier> … end Às vezes, o driver de um dispositivo precisa saber sobre outro dispositivo que pode estar em qualquer lugar na hierarquia de dispositivos. Os aplicativos atuais se resumem a EEPROMs que armazenam informações que são consumidas por algum código (por exemplo, endereço MAC). A ideia é dar aos nós de dispositivo devicetree.cbum alias que pode ser usado posteriormente para vinculá-lo à configestrutura de um driver de dispositivo. O driver precisa declarar um campo do tipo struct device *, por exemplo, dispositivos de substituição podem adicionar um alias se ele não existir, mas não podem alterar o alias para um dispositivo que já existe. Os nomes de alias são verificados quanto a conflitos na árvore base e na árvore de substituição. As referências são resolvidas após a árvore ser analisada, portanto, os aliases e as referências não precisam estar em uma ordem específica na árvore. Exemplo:

device i2c 0x50 alias my_eeprom on end

estático.c:

struct some_chip_driver_config {
        DEVTREE_CONST struct device *needed_eeprom;
};

como

Tipo de palavra-chave: Alias
Introduzido em junho de 2020, coreboot versão 4.12
- Uso: use <Alias ID> as <Alias ID 2> Esta palavra-chave é usada junto com a palavra-chave 'use' para dar um nome mais específico a um alias genérico. O autor do devicetree é livre para escolher qualquer nome de alias que seja único no devicetree. Mais tarde, ao configurar o driver, o alias pode ser usado para vincular o dispositivo ao campo de uma configuração de driver, como no exemplo a seguir. Exemplo:

chip some/chip/driver
        use my_eeprom as needed_eeprom
end

lasca

Tipo de palavra-chave: Tipo de componente
Introduzido na implementação inicial do sconfig, pré coreboot 4.0
Uso: chip

chip some/chip/driver # comment as desired
    # A chip section must have at least one device inside it
   …
end # some/chip/driver

CPU

Tipo de palavra-chave: Tipo de dispositivo
Introduzido em outubro de 2014, coreboot versão 4.0
Uso: dispositivo cpu [alias ] … fim O tipo de dispositivo cpu foi introduzido para enumerar dispositivos de CPU que não são x86 (leia-se: sem lapic). Este tipo de dispositivo não é muito usado, pois a maioria das plataformas não x86 apenas manipulam toda a configuração da CPU no nível cpu_cluster. Exemplo:

device cpu 0 on end

cluster_cpu

Tipo de palavra-chave: Tipo de dispositivo
Introduzido na implementação inicial do sconfig, pré coreboot 4.0 como apic_cluster
Atualizado em maio de 2010 - renomeado de apic_cluster para lapic_cluster
Atualizado em fevereiro de 2013 - Renomeado de lapic_cluster para cpu_cluster
Uso: device cpu_cluster <Identifier> [alias <alias ID>] <status modifier> …. end O CPU Cluster é tipicamente um dos dois dispositivos de nível superior em uma devicetree, sendo o outro o PCI Domain. Assim como a palavra-chave domain, o cpu_cluster atua como um dispositivo de ponte para conter qualquer CPU e dispositivos lapic. Em dispositivos do tipo x86, o CPU Cluster contém entradas de chip de CPU para cada soquete que então contém qualquer lapic no sistema. Em dispositivos ARM ou outros não x86, o CPU Cluster pode conter múltiplas CPUs ou pode ser marcado como 'on', deixando toda a configuração de CPU para ser manipulada no nível do CPU Cluster. Exemplo:

device cpu_cluster 0 on
    device lapic 0 on end
end

dispositivo

Tipo de palavra-chave: Tipo de componente
Introduzido em: Implementação inicial do sconfig, pré coreboot 4.0
Uso: device <device type> <Identifier> [alias <alias ID>] <status modifier>…. end Um chip define uma coleção de um ou mais dispositivos e, como tal, o dispositivo é o bloco de construção fundamental do devicetree. O bloco de dispositivos informa ao coreboot que um dispositivo está presente na placa-mãe, fornece algumas informações sobre como encontrar, acessar e trabalhar com o dispositivo com base no tipo de dispositivo. Exemplos:

device cpu_cluster 0 on
    device lapic 0 on end
end

domínio

Tipo de palavra-chave: Tipo de dispositivo
Introduzido em: Implementação inicial do sconfig, pré coreboot 4.0
Atualizado em: Fevereiro de 2013: renomeado pci_domain para domínio
Uso: device domain <identifier> [alias <alias ID>] <status modifier> … end O dispositivo do tipo domínio atua como um contêiner para um ou mais chips, definindo um segmento de barramento lógico. A partir de 2022-04-29, a palavra-chave domínio ainda é usada exclusivamente para definir segmentos de barramento PCI. Exemplo:

device domain 0 on
    device generic 0 alias dptf_policy on end
        device pci 1f.0 on                      # 8086 229c - LPC bridge
            device pnp 2e.209 off end           # GPIO 4
    end
end

Dr.

Tipo de palavra-chave: Tipo de recurso
Introduzido em: Implementação inicial do sconfig, pré coreboot 4.0
Uso: drq 0x<register #> = <drq line> Drq é usado para configurar um registro de linha de solicitação DMA legado para um dispositivo em um barramento legado - ISA/LPC/eSPI. A configuração drq é permitida somente dentro de um bloco pnp. Exemplo:

device pnp 2e.1 on              # Parallel port
    io 0x60 = 0x378
    irq 0x70 = 7
    drq 0x74 = 3
end

fim

Tipo de palavra-chave: Tipo de componente
Introduzido em: Implementação inicial do sconfig, pré coreboot 4.0
Uso: <device | chip | domain | field | fw_config> … end End é usado para fechar um chip, dispositivo, campo ou bloco fw_config. Exemplo:

chip northbridge/intel/x4x
    device domain 0 on
        chip southbridge/intel/i82801gx
            device pci 1f.0 on                 # ISA bridge
                chip superio/winbond/w83627dhg
                    device pnp 2e.1 on         # LPT
                        io 0x60 = 0x378
                        irq 0x70 = 7
                        drq 0x74 = 3
                    end # LPT
                end # superio/winbond/w83627dhg
            end # ISA Bridge
        end # Southbridge
    end # domain 0
end # Northbridge

campo

Tipo de palavra-chave: configuração de firmware
Introduzido em: maio de 2020, versão coreboot 4.12
Uso: field <Identifier string> <low bit> <high bit> [ | <low bit> <high bit> …] … end Os campos definem os bits usados nas opções de tempo de execução do Firmware config. Observe que os bits em um campo podem ser descontínuos. Todas as definições de campo devem estar dentro de um bloco fw_config. Exemplo:

field AUDIO 8 10 | 29 29
    option NONE 0
    option MAX98357_ALC5682I_I2S 1
    option MAX98373_ALC5682I_I2S 2
    option MAX98373_ALC5682_SNDW 3
    option MAX98373_ALC5682I_I2S_UP4 4
    option MAX98360_ALC5682I_I2S 5
    option RT1011_ALC5682I_I2S 6
    option AUDIO_FOO 7
    option AUDIO_BAR 8
    option AUDIO_QUUX 9
    option AUDIO_BLAH1 10
    option AUDIO_BLAH2 15
end

static_fw_config.h:

 FW_CONFIG_FIELD_AUDIO_MASK 0x20000700
 FW_CONFIG_FIELD_AUDIO_OPTION_NONE_VALUE 0x0
 FW_CONFIG_FIELD_AUDIO_OPTION_MAX98357_ALC5682I_I2S_VALUE 0x100
 FW_CONFIG_FIELD_AUDIO_OPTION_MAX98373_ALC5682I_I2S_VALUE 0x200
 FW_CONFIG_FIELD_AUDIO_OPTION_MAX98373_ALC5682_SNDW_VALUE 0x300
 FW_CONFIG_FIELD_AUDIO_OPTION_MAX98373_ALC5682I_I2S_UP4_VALUE 0x400
 FW_CONFIG_FIELD_AUDIO_OPTION_MAX98360_ALC5682I_I2S_VALUE 0x500
 FW_CONFIG_FIELD_AUDIO_OPTION_RT1011_ALC5682I_I2S_VALUE 0x600
 FW_CONFIG_FIELD_AUDIO_OPTION_AUDIO_FOO_VALUE 0x700
 FW_CONFIG_FIELD_AUDIO_OPTION_AUDIO_BAR_VALUE 0x20000000
 FW_CONFIG_FIELD_AUDIO_OPTION_AUDIO_QUUX_VALUE 0x20000100
 FW_CONFIG_FIELD_AUDIO_OPTION_AUDIO_BLAH1_VALUE 0x20000200
 FW_CONFIG_FIELD_AUDIO_OPTION_AUDIO_BLAH2_VALUE 0x20000700

fw_config

Tipo de palavra-chave: configuração de firmware
Introduzido em: maio de 2020, versão coreboot 4.12
Uso: fw_config Fw_config é o token de nível superior para definir campos de configuração de firmware. Todas as definições de campo e opção devem estar dentro do bloco fw_config. Observe que a tabela pode ser definida antes que qualquer chip seja configurado. Exemplo:

fw_config
    field USB_DB 0 1
        option USB_DB_A1_PS8811_C1_PS8818 0
        option USB_DB_A1_ANX7491_C1_ANX7451 1
    end
    field FORM_FACTOR 2
        option FORM_FACTOR_CLAMSHELL 0
        option FORM_FACTOR_CONVERTIBLE 1
    end
end

genérico

Tipo de palavra-chave: Tipo de dispositivo
Introduzido em: maio de 2016, versão coreboot 4.4
Uso: device generic <identifier> [alias <alias ID>] <status modifier> … end Isso permite que o devicetree descreva um dispositivo que não tem um barramento específico, mas pode precisar ser descrito em tabelas para o sistema operacional. Por exemplo, alguns chips podem ter várias conexões GPIO que precisam ser descritas, mas não se enquadram em nenhum outro dispositivo. Exemplo:

device pci 0c.0 on                        # CNVi
    chip drivers/wifi/generic
        register "wake" = "GPE0A_CNVI_PME_STS"
        device generic 0 on end
    end
end

gpio

Tipo de palavra-chave: Tipo de dispositivo
Introduzido em: dezembro de 2020, coreboot versão 4.13
Uso: dispositivo gpio [alias ] … fim A ideia geral por trás disso é que cada chip pode ter gpios que devem ser acessíveis de uma forma muito genérica por qualquer driver através do devicetree. O chip que implementa as operações gpio específicas do chip tem que atribuí-las à estrutura de operações de dispositivo genérico, que então é atribuída ao dispositivo gpio durante a sondagem do dispositivo. Veja CB:48583 para saber como isso é feito para os SoCs usando intel/blocks/gpio. O dispositivo gpio então pode ser adicionado ao devicetree com um nome de alias como no exemplo a seguir:

chip soc/whateverlake
    device gpio 0 alias soc_gpio on end
    ...
end

Qualquer driver que exija acesso a este dispositivo gpio precisa ter um ponteiro de dispositivo (ou vários) e uma opção para especificar o gpio a ser usado na configuração do chip, como esta:

struct drivers_ipmi_config {
    ...
    DEVTREE_CONST struct device *gpio_dev;
    u16 post_complete_gpio;
    ...
};

O dispositivo soc_gpiopode então ser vinculado ao driver do chip gpio_dev acima usando a sintaxe use ... as ..., que foi introduzida no commit 8e1ea52:

chip drivers/ipmi
    use soc_gpio as gpio_dev
    register "bmc_jumper_gpio" = "GPP_D22"
    ...
end

O driver IPMI pode então usar as operações gpio genéricas sem qualquer conhecimento das especificações do chip:

unsigned int gpio_val;
const struct gpio_operations *gpio_ops;
gpio_ops = dev_get_gpio_ops(conf->gpio_dev);
gpio_val = gpio_ops->get(conf->bmc_jumper_gpio);

Para um exemplo completo, dê uma olhada em CB:48096 e CB:48095.

escondido

Tipo de palavra-chave: Modificador de status de enumeração
Introduzido em: setembro de 2018, coreboot versão 4.8
Atualizado em: fevereiro de 2020, coreboot versão 4.11
Uso: device <device type> <identifier> [alias <alias ID>] hidden … end A palavra-chave "Hidden" foi adicionada para oferecer suporte a dispositivos que compartilham o mesmo driver para atualizar seu status ACPI com valores diferentes. Se um dispositivo for marcado como Oculto, ele omite o campo "SHOW_IN_UI", o que impede que o dispositivo apareça na interface do usuário do OSPM. Isso foi adicionado para impedir que dispositivos específicos do ChromeOS apareçam no Windows, por exemplo. Não parece que essa palavra-chave tenha sido realmente usada nessa capacidade, mas o código para isso ainda está presente. Em 2020, o uso da palavra-chave "Oculto" foi expandido para corrigir o problema de dispositivos PCI que foram ocultados ao desabilitar o acesso ao espaço de configuração. Como os IDs do dispositivo/fornecedor são lidos como 0xffffffff do dispositivo oculto, parece que não há nenhum dispositivo PCI localizado naquele Barramento/Dispositivo/Função. Isso faz com que o coreboot remova o dispositivo no final da enumeração PCI. Para corrigir isso, se um dispositivo usar 'hidden' em vez de 'on', então será assumido durante a enumeração PCI que o dispositivo realmente existe, e ele não será removido. Isso permite que o coreboot atribua manualmente recursos ao dispositivo, mesmo que ele não pareça existir. Exemplo:

device pci 1f.2 alias pmc hidden end

estático.c:

.enabled = 1,
.hidden = 1,
.mandatory = 0,

i2c

Tipo de palavra-chave: Tipo de dispositivo
Introduzido em: Implementação inicial do sconfig, pré coreboot 4.0
Uso: device I2c <identifier> [alias <alias ID>] <status modifier> … end Exemplo:

device i2c 2c on end
chip drivers/i2c/generic
register "hid" = ""ELAN0000""
    register "desc" = ""ELAN Touchpad""
    register "irq_gpio" = "ACPI_GPIO_IRQ_LEVEL_LOW(GPIO_9)"
    register "wake" = "GEVENT_22"
    register "probed" = "1"
    device i2c 15 on end
end

herdar

Tipo de palavra-chave: subsistema
Introduzido em: março de 2011, coreboot versão 4.0
Uso: subsystemid beee c001 inherit Usado para modificar a palavra-chave subsystemid, herdar faz com que o ID se aplique a todos os subdispositivos e funções. Exemplo:

device pci 00.0 on
    subsystemid 0xdead 0xbeef inherit
end

esse

Tipo de palavra-chave: Recurso
Introduzido em: Implementação inicial do sconfig, pré coreboot 4.0
Uso: io 0x<address> = 0x<value> O comando io é usado para definir o registro io de um dispositivo legado para um valor. Exemplo:

device pnp 4e.06 on                # Keyboard
    io 0x60            = 0x0060
    io 0x62            = 0x0064
    irq 0x70        = 1
end

iópico

Tipo de palavra-chave: Tipo de dispositivo
Introduzido em:
Uso: device ioapic <identifier> [alias <alias ID>] <status modifier> … end Exemplo:

ioapic_irq

Tipo de palavra-chave: tipo Mpinit
Introduzido em: junho de 2012, coreboot versão 4.0
Uso: ioapic_irq <APICID> <INTA|INTB|INTC|INTD> <INTPIN> Esta palavra-chave é usada para dar suporte à autogeração do MPTABLE a partir do devicetree.cb. Isso é feito por um write_smp_table() declarado weak em mpspec.c. Se a placa-mãe não fornecer sua própria função, esta implementação genérica é chamada. A diretiva ioapic_irq pode ser usada em dispositivos pci e pci_domain. Se não houver nenhuma diretiva, o código autogen percorre a árvore de volta ao pci_domain e para no primeiro dispositivo que define tal diretiva, e usa essa informação para gerar a entrada de acordo com as regras de roteamento PCI IRQ. Exemplo:

irq

Tipo de palavra-chave: Tipo de recurso
Introduzido na implementação inicial do sconfig, pré coreboot 4.0
Uso: irq 0x<address> = 0x<value> Irq é usado para configurar um registro de linha de solicitação de interrupção legado para um dispositivo em um barramento legado - ISA/LPC/eSPI. A configuração irq é permitida somente dentro de um bloco pnp. Exemplo:

irq 0xc5 = 0x1f

chip superio/fintek/f71808a
    device pnp 4e.4 on    # Hardware monitor
        io 0x60 = 0x295
        irq 0x70 = 0
    end
end

Lápico

Tipo de palavra-chave: Tipo de dispositivo
Introduzido na implementação inicial do sconfig, pré coreboot 4.0
Atualizado em maio de 2010 - renomeado apic para lapic
Uso: device lapic <identifier> [alias <alias ID>] <status modifier> … end Define um dispositivo lapic em uma placa-mãe x86. Exemplo:

device cpu_cluster 0 on          # (L)APIC cluster
    chip cpu/intel/slot_1        # CPU socket 0
        device lapic 0 on end    # Local APIC of CPU 0
    end
    chip cpu/intel/slot_1        # CPU socket 1
        device lapic 1 on end    # Local APIC of CPU 1
    end
end

obrigatório

Tipo de palavra-chave: Modificador de status de enumeração
Introduzido em: fevereiro de 2020, versão coreboot 4.11
Uso: device <device type> <identifier> [alias <alias ID>] mandatory … end A palavra-chave Mandatory permite varredura mínima de PCI, o que acelera o processo de inicialização. Somente dispositivos marcados como "mandatory" são habilitados e escaneados durante a enumeração de PCI quando a opção MINIMAL_PCI_SCANNING Kconfig está habilitada. Se MINIMAL_PCI_SCANNING não estiver habilitado, isso significa o mesmo que 'on' static.c:

.enabled = 1,
.hidden = 0,
.mandatory = 1,

exemplo:

device pci 1f.0 mandatory  # LPC
    chip drivers/pc80/tpm
        device pnp 0c31.0 on end
    end # tpm
end # LPC

mmio

Tipo de palavra-chave: Tipo de dispositivo
Introduzido em janeiro de 2018, coreboot versão 4.7
Uso: device mmio 0x<address> [alias <alias ID>] <status modifier> … end A palavra-chave mmio permite que dispositivos de IO mapeados em memória fixa sejam atribuídos a valores fornecidos. Plataformas AMD realizam uma quantidade significativa de configuração por meio desses endereços MMIO, incluindo configuração de barramento I2C. Exemplo:

device mmio 0xfedc9000 alias uart_0 off end
device mmio 0xfedca000 alias uart_1 off end
device mmio 0xfedc2000 on                      # I2C 0
    chip drivers/generic/adau7002
        device generic 0.0 on end
    end
    chip drivers/i2c/da7219
        register "irq_gpio" = "ACPI_GPIO_IRQ_EDGE_LOW(GPIO_14)"
    end
    chip drivers/generic/max98357a
        register "hid" = ""MX98357A""
        register "sdmode_delay" = "5"
        device generic 0.1 on end
    end
end # I2C 0

desligado

Tipo de palavra-chave: Modificador de status de enumeração
Introduzido em: Implementação inicial do sconfig, pré coreboot 4.0
Uso: device <device type> <identifier> [alias <alias ID>] off … end Indica que o dispositivo deve ser desabilitado se possível e não deve ser enumerado ou configurado. Para desabilitar um dispositivo, o código para desabilitá-lo deve estar presente no código do chipset/SoC, embora nem sempre seja possível desabilitar o dispositivo. Observe que se um dispositivo (especialmente dispositivos PCI) for marcado como 'off', mas não for desabilitado, o SO ou um driver pode descobrir o dispositivo durante sua sequência de enumeração e atribuir recursos a ele de qualquer maneira. static.c:

.enabled = 0
.hidden = 0,
.mandatory = 0,

exemplo:

device usb 2.6 off end
device pnp 2e.0 off end # FDC
device pci 15.2 off end

sobre

Tipo de palavra-chave: Modificador de status de enumeração
Introduzido em: Implementação inicial do sconfig, pré coreboot 4.0
Uso: device <device type> <identifier> [alias <alias ID>] on … end Marca um dispositivo como presente e habilitado. Isso indica que o dispositivo deve ser enumerado e configurado. static.c:

.enabled = 1
.hidden = 0,
.mandatory = 0,

Exemplo:

device lapic 0 on end
device pci 00.0 on  end # Host Bridge
device pnp 0c31.0 on end

opção

Tipo de palavra-chave: configuração de firmware
Introduzido em:
Uso: option <name> <value> As opções definem os valores que podem ser usados em um campo de configuração de firmware. A palavra-chave option pode ser usada somente dentro de um campo, que pode ser usado somente dentro de um bloco fw_config. Exemplo:

fw_config
    field OLED_SCREEN 28
        option OLED_NOT_PRESENT 0
        option OLED_PRESENT 1
    end
end

PCI-e

Tipo de palavra-chave: Tipo de dispositivo
Introduzido em: Implementação inicial do sconfig, pré coreboot 4.0
Uso: device pci <dev.func> [alias <alias ID>] <status modifier> …. end O tipo de dispositivo pci define um dispositivo PCI ou PCIe no barramento lógico PCI. Recursos para todos os dispositivos PCI são atribuídos automaticamente, ou devem ser atribuídos em código se não forem padrão. Atualmente, apenas um único segmento é suportado, mas há trabalho para tornar múltiplos segmentos diferentes suportados, cada um com um barramento 0. Como o barramento não é especificado, presume-se que todos os dispositivos pci que não estão atrás de um dispositivo de ponte pci estão no barramento 0. Se houver barramentos pci adicionais em um chip, eles podem ser adicionados atrás de seu dispositivo de ponte. Exemplos:

device pci 1a.0 on end # USB2 EHCI #2
device pci 1b.0 on # High Definition Audio
    subsystemid 0x1a86 0x4352
end

Exemplo - Barramento ISA sob ponte PCI para ISA:

device pci 4.0 on                        # ISA bridge
    chip superio/winbond/w83977tf        # Super I/O
        device pnp 3f0.2 on              # COM1
            io 0x60 = 0x3f8
            irq 0x70 = 4
        end
    end
end

Exemplo - Barramento PCI sob uma ponte PCI para PCI:

device pci 08.0 on end                    # Dummy Host Bridge, do not disable
device pci 08.1 alias gpp_bridge_a off    # Internal GPP Bridge 0 to Bus A
    device pci 0.0 alias gfx off end            # Internal GPU (GFX)
    device pci 0.1 alias gfx_hda off end        # Display HDA (GFXAZ)
end

pnp

Tipo de palavra-chave: Tipo de dispositivo
Introduzido em: Implementação inicial do sconfig, pré coreboot 4.0
Uso: device pnp <Identifier> [alias <alias ID>] <status modifier>…. end pnp é usado para definir um dispositivo endereçado por IO dentro de um chip em um barramento legado - ISA, LPC ou eSPI. O identificador é o endereço de IO usado para acessar o chip, seguido pelo identificador do dispositivo dentro do chip. Os identificadores de recursos io, irq e drq são permitidos somente dentro de um dispositivo pnp. Exemplo:

chip superio/ite/it8783ef
    device pnp 2e.0 off end    # Floppy
    device pnp 2e.1 on    # COM 1
        io 0x60 = 0x3f8
        irq 0x70 = 4
    end
end

sonda

Tipo de palavra-chave: configuração de firmware
Introduzido em maio de 2020, coreboot versão 4.12
Uso: probe <Field Name> <Option Name> Os campos e opções podem ser usados para sondar um dispositivo e fazer com que esse dispositivo seja desabilitado se não for encontrado no momento da inicialização. Exemplo:

fw_config
    field FEATURE 0 0
        option DISABLE 0
        option ENABLE 1
    end
end
chip drivers/generic/feature
    device generic 0 on
        probe FEATURE ENABLE
    end
end

referência

Tipo de palavra-chave: Tipo de dispositivo (alias)
Introduzido em julho de 2020, coreboot versão 4.12
Uso: device REF <Identifier> <status modifier>…. end Isso permite que o chipset atribua nomes de alias a dispositivos, bem como defina valores de registro padrão. Isso funciona tanto para o baseboard devicetree.cb quanto para o variant overridetree.cb. Exemplo: chipset.cb:

device pci 15.0 alias i2c0 off end

dispositivotree.cb:

device ref i2c0 on end

registrar

Tipo de palavra-chave: Registro
Introduzido em: Implementação inicial do sconfig, pré coreboot 4.0
Uso: register "name" = "value" A palavra-chave register foi inicialmente destinada a fornecer apenas isso - informações para valores de registro de dispositivo. Ao longo dos anos, seu uso foi expandido para muito mais do que isso, tornando-se um mecanismo de configuração geral. Todos os valores definidos pela palavra-chave register DEVEM ser definidos no arquivo chip.h. A palavra-chave register funciona apenas no nível do chip, não no nível do dispositivo. Qualquer registro definido no arquivo chip.h que não esteja definido no arquivo devicetree é definido como zero. Para colocar um valor entre aspas duplas, use dois conjuntos de aspas: register "name" = ""string"" Exemplos:

register "desc" = ""USB2 Type-A Rear Lower""
register "pcie_power_limits" = "{ { 10, 0 }, { 0, 0 }, { 0, 0 },
                                  { 0, 0 }, { 10, 0 }, { 0, 0 } }"
register "SataPortsEnable[0]" = "1"
register "generic.irq"              = "ACPI_IRQ_LEVEL_LOW(GPP_B3_IRQ)"
register "common_soc_config" = "{
                                    // Touchpad I2C bus
                                    .i2c[0] = {
                                        .speed = I2C_SPEED_FAST,
                                        .rise_time_ns = 80,
                                        .fall_time_ns = 110,
                                    },
                                }"

smbios_dev_info

Tipo de palavra-chave: smbios
Introduzido em: maio de 2019, versão 4.9 do coreboot
Uso: smbios_dev_info <Identifier> Especifique o ID da instância e RefDes (Designação de Referência) dos dispositivos onboard. A SMBIOS_TYPE41_PROVIDED_BY_DEVTREEopção Kconfig permite usar essa sintaxe para controlar as entradas Type 41 geradas (Onboard Devices Extended Information). Quando essa opção está habilitada, as entradas Type 41 são geradas automaticamente apenas para dispositivos com um ID de instância definido. Isso evita ter que manter o controle de quais IDs de instância foram usados para cada classe de dispositivo. Usar smbios_dev_infowhen SMBIOS_TYPE41_PROVIDED_BY_DEVTREEnão estiver habilitado resultará em um erro de tempo de compilação, pois a sintaxe não tem sentido nesse caso. Isso é feito com proteções do pré-processador em torno dos membros Type 41 em struct devicee o código que usa os membros protegidos. Embora o uso do pré-processador não seja particularmente elegante, ajustar a sintaxe e/ou gramática do devicetree dependendo de uma opção Kconfig é provavelmente ainda pior. Exemplo:

device pci 1c.0 on        # PCIe Port #1
    device pci 00.0 on
        smbios_dev_info 6
    end
end
device pci 1c.1 on        # PCIe Port #2
    device pci 00.0 on
        smbios_dev_info 42 "PCIe-PCI Time Machine"
    end
end

smbios_slot_desc

Tipo de palavra-chave: smbios
Introduzido em: maio de 2019, versão 4.9 do coreboot
Uso: smbios_slot_desc** <type> <length> [designation] [data width] Adicione o novo campo 'smbios_slot_desc', que aceita de 2 a 4 argumentos. O campo é válido somente para dispositivos PCI e compilado somente se a geração de tabela SMBIOS estiver habilitada. Argumentos smbios_slot_desc - descritos em src/include/smbios.h:

tipo de slot: enum misc_slot_type
comprimento do slot: enum misc_slot_length
designação de slot (opcional): sequência de texto
largura de dados do slot (opcional): enum slot_data_bus_bandwidth Exemplo:

device pci 1c.1 on
    smbios_slot_desc "SlotTypePciExpressGen3X16" "SlotLengthOther" "SLOT2" "SlotDataBusWidth8X"
end # PCIe Port #2 Integrated Wireless LAN

espi

Tipo de palavra-chave: Tipo de dispositivo
Introduzido em: fevereiro de 2017, coreboot versão 4.5
Uso: dispositivo SPI [alias ] …. fim O dispositivo SPI recebe apenas um parâmetro, o chip-select para o dispositivo no barramento SPI. Exemplo:

device spi 0 alias spi_tpm on end

subsistemaid

Tipo de palavra-chave: Subsistema
Introduzido em: março de 2011, coreboot versão 4.0
Uso: subsystemid <vendor> <device> [inherit] Define um ID de subsistema PCI. Se o usuário quiser que esse ID seja herdado para todos os subdispositivos/funções, ele pode adicionar a palavra-chave 'inherit' após o ID. Se o usuário não quiser herdar o valor do subsistema para um único dispositivo, ele pode especificar 'subsystemid 0 0' neste dispositivo em particular. Exemplo:

device pci 00.0 on
    subsystemid 0xdead 0xbeef
end

device pci 00.0 on
    subsystemid 0xdead 0xbeef inherit
end

USB

Tipo de palavra-chave: Tipo de dispositivo
Introduzido em: maio de 2018, versão coreboot 4.7
Uso: device usb <Identifier> [alias <alias ID>] <status modifier> ... end Isso suporta a descrição de portas USB no devicetree. Ele permite que um local de porta USB seja descrito na árvore com informações de configuração e que o código ACPI seja gerado para fornecer essas informações ao SO. O símbolo usb funciona com a operação scan_usb_bus() para escanear pontes em busca de dispositivos para que uma árvore de portas e hubs possa ser criada. O endereço do dispositivo é computado com um 'tipo de porta' e um 'id de porta' que é flexível para o SOC manipular dependendo de sua configuração USB específica. Isso também permite que portas USB2 e USB3 sejam descritas separadamente. Por exemplo, uma placa pode ter dispositivos em duas portas, uma com um dispositivo USB2 e outra com um dispositivo USB3, ambas conectadas a um controlador xHCI com um hub raiz:

             xHCI
               |
            RootHub
            |     |
        USB2[0]  USB3[2]

Isto é descrito pelo seguinte exemplo:

device pci 14.0 on
    chip drivers/usb/acpi
        register "name" = ""Root Hub""
        device usb 0.0 on
            chip drivers/usb/acpi
                register "name" = ""USB 2.0 Port 0""
                device usb 2.0 on end
            end
            chip drivers/usb/acpi
                register "name" = ""USB 3.0 Port 2""
                device usb 3.2 on end
            end
        end # device usb 0.0
    end # chip drivers/usb/acpi
end # device pci 14.0

usar

Tipo de palavra-chave: Alias
Introduzido em setembro de 2020, coreboot versão 4.12
Uso: use <Alias ID> as <Alias ID2> O autor do devicetree é livre para escolher qualquer nome de alias que seja único no devicetree. Mais tarde, ao configurar o driver para uma placa, o alias pode ser usado para vincular o dispositivo ao campo de uma configuração de driver, dando a ele um nome específico. Exemplo:

chip some/chip/driver
    use my_eeprom as needed_eeprom
end