[PATCH 10/10] docs/translations/pt_BR: admin-guide: add efi-stub.rst

[Daniel Pereira <danielmaraboo@gmail.com>]

Add translation of efi-stub.rst to Portuguese and update
admin-guide/index.rst.

Signed-off-by: Daniel Pereira <danielmaraboo@gmail.com>
---
 .../pt_BR/admin-guide/efi-stub.rst            | 102 ++++++++++++++++++
 .../translations/pt_BR/admin-guide/index.rst  |   2 +-
 2 files changed, 103 insertions(+), 1 deletion(-)
 create mode 100644 Documentation/translations/pt_BR/admin-guide/efi-stub.rst

diff --git a/Documentation/translations/pt_BR/admin-guide/efi-stub.rst b/Documentation/translations/pt_BR/admin-guide/efi-stub.rst
new file mode 100644
index 000000000..d21f134ab
--- /dev/null
+++ b/Documentation/translations/pt_BR/admin-guide/efi-stub.rst
@@ -0,0 +1,102 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+=================
+O EFI Boot Stub
+=================
+
+Nas plataformas x86 e ARM, uma zImage/bzImage do kernel pode se passar por
+uma imagem PE/COFF, convencendo assim os carregadores de firmware EFI a
+carregá-la como um executável EFI. O código que modifica o cabeçalho da bzImage,
+juntamente com o ponto de entrada específico do EFI para o qual o carregador de
+firmware salta, são conhecidos coletivamente como o "EFI boot stub", e residem
+em arch/x86/boot/header.S e drivers/firmware/efi/libstub/x86-stub.c, respectivamente.
+Para ARM, o stub EFI é implementado em arch/arm/boot/compressed/efi-header.S e
+drivers/firmware/efi/libstub/arm32-stub.c. O código do stub EFI compartilhado
+entre arquiteturas está em drivers/firmware/efi/libstub.
+
+Para arm64, não há suporte a kernel compactado, portanto a própria Imagem se
+passa por uma imagem PE/COFF e o stub EFI é vinculado diretamente ao kernel. O
+stub EFI para arm64 reside em drivers/firmware/efi/libstub/arm64.c e
+drivers/firmware/efi/libstub/arm64-stub.c.
+
+Ao usar o EFI boot stub, é possível inicializar um kernel Linux sem o uso de um
+carregador de boot EFI convencional, como o grub ou elilo. Como o EFI boot stub
+desempenha as tarefas de um carregador de inicialização, em certo sentido ele *É*
+o carregador de inicialização.
+
+O EFI boot stub é ativado com a opção de kernel CONFIG_EFI_STUB.
+
+
+Como instalar bzImage.efi
+-------------------------
+
+A bzImage localizada em arch/x86/boot/bzImage deve ser copiada para a Partição
+de Sistema EFI (ESP - EFI System Partition) e renomeada com a extensão ".efi".
+Sem a extensão, o carregador de firmware EFI se recusará a executá-la. Não é
+possível executar bzImage.efi a partir dos sistemas de arquivos normais do Linux
+porque o firmware EFI não possui suporte para eles. Para ARM, a
+arch/arm/boot/zImage deve ser copiada para a partição de sistema e pode não
+precisar ser renomeada. Da mesma forma, para arm64, arch/arm64/boot/Image deve
+ser copiada, mas não necessariamente renomeada.
+
+
+Passando parâmetros do kernel a partir do shell EFI
+---------------------------------------------------
+
+Argumentos para o kernel podem ser passados após bzImage.efi, por exemplo::
+
+	fs0:> bzImage.efi console=ttyS0 root=/dev/sda4
+
+A opção "initrd="
+-----------------
+
+Como a maioria dos carregadores de inicialização, o stub EFI permite que o
+usuário especifique múltiplos arquivos initrd usando a opção "initrd=". Este é
+o único parâmetro de linha de comando específico do stub EFI; tudo o mais é
+passado para o kernel quando ele inicializa.
+
+O caminho para o arquivo initrd deve ser um caminho absoluto a partir do início
+da ESP; nomes de caminhos relativos não funcionam. Além disso, o caminho é no
+estilo EFI e os elementos de diretório devem ser separados com barras invertidas
+(\). Por exemplo, dada a seguinte estrutura de diretórios::
+
+  fs0:>
+	Kernels\
+			bzImage.efi
+			initrd-large.img
+
+	Ramdisks\
+			initrd-small.img
+			initrd-medium.img
+
+para inicializar com o arquivo initrd-large.img se o diretório de trabalho atual
+for fs0:\Kernels, o seguinte comando deve ser usado::
+
+	fs0:\Kernels> bzImage.efi initrd=\Kernels\initrd-large.img
+
+Observe como bzImage.efi pode ser especificado com um caminho relativo. Isso ocorre
+porque a imagem que estamos executando é interpretada pelo shell EFI, que entende
+caminhos relativos, enquanto o restante da linha de comando é passado para bzImage.efi.
+
+.. hint::
+   Também é possível fornecer um initrd usando um protocolo UEFI específico do
+   Linux no momento da inicialização. Consulte :ref:`pe-coff-entry-point` para
+   obter detalhes.
+
+A opção "dtb="
+--------------
+
+Para as arquiteturas ARM e arm64, uma árvore de dispositivos (device tree) deve ser
+fornecida ao kernel. Normalmente, o firmware deve fornecer a árvore de dispositivos
+através da EFI CONFIGURATION TABLE. No entanto, a opção de linha de comando "dtb="
+pode ser usada para sobrescrever a árvore de dispositivos fornecida pelo firmware
+ou para fornecer uma quando o firmware não puder fazê-lo.
+
+Observe: O firmware adiciona informações de configuração em tempo de execução à
+árvore de dispositivos antes de inicializar o kernel. Se dtb= for usado para
+sobrescrever a árvore de dispositivos, quaisquer dados em tempo de execução
+fornecidos pelo firmware serão perdidos. A opção dtb= deve ser usada apenas como
+uma ferramenta de depuração ou como último recurso quando uma árvore de dispositivos
+não for fornecida na EFI CONFIGURATION TABLE.
+
+"dtb=" é processado da mesma maneira que a opção "initrd=" descrita acima.
diff --git a/Documentation/translations/pt_BR/admin-guide/index.rst b/Documentation/translations/pt_BR/admin-guide/index.rst
index 40397ef77..f0f096a74 100644
--- a/Documentation/translations/pt_BR/admin-guide/index.rst
+++ b/Documentation/translations/pt_BR/admin-guide/index.rst
@@ -60,10 +60,10 @@ Inicializando o kernel
 
    bootconfig
    kernel-parameters
+   efi-stub
 
 Todolist:
 
-*   efi-stub
 *   initrd
 
 Rastreando e identificando problemas
-- 
2.47.3