Trabalho 3. MC404, 1 o semestre de 2012, turmas A e B 19 de junho de 2012

Transcrição

1 Trabalho 3 MC404, 1 o semestre de 2012, turmas A e B 19 de junho de 2012 O trabalho 3 é dividido em duas partes: código de sistema e código de usuário. Estas partes estão descritas nas seções abaixo. Você deve começar o trabalho a partir de um código esqueleto fornecido (veja endereço no apêndice). A estrutura do código de sistema fornecido está separada em diversos arquivos, mas é apenas uma sugestão e você pode modificá-la à vontade. Esta sugestão, entretanto, tenta incentivar a implementação em múltiplos arquivos: uma forma mais organizada e fácil de programar. A entrega deve ser um arquivo.tar.bz2 comprimido contendo a mesma estrutura de pastas do código esqueleto: uma pasta para a parte de sistema e uma pasta para a parte de usuário. Cada pasta deve conter, além do código fonte, também seu próprio Makefile para construir o código correspondente. Lembre-se, portanto, de ir atualizando o Makefile conforme for fazendo seu projeto. 1 Código de Sistema O seu código de sistema deve implementar um diminuto sistema operacional capaz de atender às chamadas de sistema read, write, settimeofday, gettimeofday e exit. A chamada de sistema write deve escrever o conteúdo da cadeia de bytes, fornecida como argumento, no dispositivo de saída serial, a UART. A chamada de sistema read deve ler uma sequência de nbyte bytes do dispositivo de entrada serial, a UART. Note que nbyte é o terceiro argumento da chamada de sistema read. A chamada de sistema gettimeofday e settimeofday devem retornar e gravar, respectivamente, a data atual. Esta data é representada por um número natural de 32 bits que indica a quantidade de segundos passados desde o início da UNIX epoch, equivalente à zero hora de 1 o de janeiro de A chamada de sistema exit finaliza o programa - entra em um loop infinito. A data atual deve ser gravada em uma variável de memória global de 32 bits no endereço 0x30 da memória do ARM. Utilize a diretiva.org para informar ao montador o local onde sua variável deve ser alocada. 2 Código de Usuário O código de usuário (aplicativo) deve, usando as chamadas de sistema read, write, gettimeofday e settimeofday implementar um programa que recebe comandos para impressão de data e hora atual e ajuste do relógio de sistema. Trata-se de um pequeno shell, o programa que lê linhas de comando no Linux, limitado a interpretar apenas um único comando: o comando date 1. O código de usuário deve ser feito usando a linguagem C, mas sem recorrer às bibliotecas disponibilizadas junto ao compilador. Isto significa que você não deve utilizar funções da biblioteca padrão C, como printf. O aplicativo deve iniciar imprimindo a cadeia de caracteres sh$, que informa ao usuário que o shell está esperando por um novo comando. 1 Digite man 1 date em um shell (de verdade) Linux para ver detalhes de como esse comando funciona. 1

2 2.1 Parâmetros de date O seu pequeno shell deve implementar somente o comando date com o subconjunto dos parâmetros definido abaixo. Estes parâmetros são: 1. Formato da impressão, indicado pelo caractere +. Tudo que segue este caractere, entre aspas duplas, é chamado de cadeia de caracteres de formato e é montado de modo semelhante à cadeia de caracteres de formato da função printf. O usuário poderá utilizar os especificadores %H para a hora (0 a 23), %M para o minuto, %S para o segundo, %d para o dia do mês, %m para o mês (1 a 12), %Y para o ano e %B para o nome por extenso do mês, em português e com a inicial em maiúscula. O usuário também pode usar o formato %n quando quiser que uma nova linha seja impressa. Qualquer outra cadeia de caracteres que não seja precedida por porcentagem deve ser copiada verbatim 2 para a saída. Exemplo: sh $ date +"A hora é %H, o minuto é %M e o segundo é %S.%n%d de %B de %Y." A hora é 17, o minuto é 57 e o segundo é de Junho de sh $ No código acima, o caractere de escape \ foi utilizado apenas para escrever um comando shell em duas linhas para que coubesse neste documento. O seu programa não precisa ter suporte a este tipo de entrada e, portanto, interprete o comando acima como se estivesse todo em uma única linha e sem o caractere de escape \. 2. Parâmetro -s, utilizado para ajustar o horário do relógio. O parâmetro deve ser passado como em -s"string", em que STRING é uma cadeia de caracteres que contém a nova hora. O formato deve seguir o padrão %H:%M:%S %d/%m/%y (vide formatos no item anterior). Exemplo: sh $ date -s"22:00:00 01/01/2000" Na ausência de parâmetros, o seu comando date deve imprimir a data atual usando um formato padrão. Este padrão é o "%H:%M:%S %d/%m/%y". 2 Sem alterações 2

3 A Como funcionam as syscalls no ARM EABI Você deve implementar, na parte do trabalho correspondente ao código de sistema, um sistema capaz de atender as chamadas de sistemas read, write, gettimeofday, settimeofday e exit. Para isso, note quais são os parâmetros das chamadas de sistema segundo o padrão POSIX para sistemas operacionais baseados em UNIX, segundo a Tabela 1. syscall Parâmetros Descrição read R0 - descritor do arquivo. R1 - ponteiro para o buffer de leitura. R2 - número de bytes a serem lidos. write R0 - descritor do arquivo. R1 - ponteiro para o buffer de escrita. R2 - número de bytes a serem escritos. gettimeofday R0 - ponteiro para uma estrutura do tipo timeval. R1 - pointeiro para uma estrutura do tipo timezone A chamada de sistema read (consulte man 2 read em um shell de Linux) lê R2 bytes do arquivo cujo descritor está em R0 e armazena na área de memória apontada por R1. O descritor de número 0 indica a entrada padrão aberta pelo shell. O número da chamada de sistema read é 3. A chamada de sistema write escreve R2 bytes que estão na área de memória apontada por R1 no arquivo cujo descritor está em R0. O descritor de número 1 indica a saída padrão, conhecida como stdout em C e aberta automaticamente pelo shell. O número da chamada de sistema write é 4. Essa chamada de sistema retorna 0 em caso de sucesso ou -1 caso contrário. Para os argumentos que forem diferente de NULL (0), preenche a estrutura com as informações solicitadas. Ignore o argumento timezone. Execute o comando man 2 gettimeofday para mais informações. O número dessa chamada de sistema é 78. settimeofday Idem. Igual à chamada de sistema anterior, mas utiliza as informações para configurar uma nova hora no sistema. O número dessa chamada de sistema é 79. exit R0 possui o cod. de retorno. Como estamos implementando um sistema simples, o tratamento dessa syscall deve simplesmente entrar em um loop infinito. Tabela 1: Exemplo de chamadas de sistema do Linux. Na convenção mais recente ARM EABI, para realizar uma chamada ao sistema, você deve colocar o número da chamada de sistema no registrador R7, e os parâmetros seguem a mesma convenção de uma chamada de função comum (devem estar nos registradores R0 a R3) e o valor de retorno é passado no registrador R0. Para realizar a chamada de sistema, você deve utilizar a instrução svc 0. Esta instrução irá gerar uma exceção e fazer com que o PC (apontador para a instrução a ser executada) aponte para a posição e troque o modo do processador para SUPERVISOR. A implementação de uma chamada de sistema, portanto, é similar à implementação de interrupções do laboratório 10 (apresentado no dia 6 de junho). Porém, você recebe um número em R7 correspondendo ao número da syscall, e os parâmetros nos registradores. Lembre-se que, para retornar do tratador de chamadas de sistema para o código do usuário que chamou a syscall, você deve utilizar uma instrução especial como movs pc, lr para recuperar o CPSR original, modificando o modo do processador. Mais detalhes sobre a troca de modos e o serviço de interrupções e syscalls no processador ARM estão disponíveis no enunciado do laboratório 10. Não é necessário que seu sistema administre arquivos e descritores de arquivos. Portanto, ignore o primeiro parâmetro das chamadas de sistema reade write, que dizem respeito ao número do descritor de 3

4 arquivo. Ou seja, independente do valor do descritor de arquivo, a chamada de sistema read deve ler os bytes do dispositivo UART e a chamada de sistema write deve escrever os bytes no dispositivo UART. Esta é uma pequena simplificação que deve ser adotada no seu sistema em relação ao um sistema operacional POSIX real. A.1 read Para implementar a chamada de sistema read, ignore o parâmetro que corresponde ao descritor de arquivos. Interprete qualquer chamada para read como um pedido do aplicativo para ler dados da UART. A quantidade exata de bytes solicitados estará em R2, e você deverá gravar os bytes lidos no buffer cujo ponteiro está em R1. Retorne o número de bytes lidos com sucesso ou -1 caso tenha ocorrido algum erro. O comportamento usual de read, quando lendo de uma entrada que é uma cadeia de bytes (como o terminal), diferentemente da leitura de um arquivo, é de retornar assim que o usuário pressiona enter, inserindo o caractere \n (newline) no buffer. Portanto, se um aplicativo solicita ler caracteres, e os dados disponíveis são "Hello world!\npróxima linha\n", read irá colocar apenas 13 caracteres no buffer, correspondendo à leitura da primeira linha, e retornar 13 (o número de caracteres lidos). A próxima linha só é lida na próxima chamada à read. Você tem a liberdade de implementar a chamada de sistema read como achar mais adequado, mas caso se desvie desse comportamento, terá dificuldades para implementar o aplicativo que lê linha a linha da UART (interpretando comandos). Note que, para a chamada de sistema read, é normal retornar um número de caracteres lidos menor do que o solicitado, e o aplicativo normalmente conta com isso. A.2 write De forma análoga à chamada de sistema read, implemente a chamada de sistema write ignorando o primeiro parâmetro que corresponde ao descritor de arquivo. Interprete qualquer chamada para write como um pedido do aplicativo para escrever dados na UART. Escreva R2 bytes do buffer cujo ponteiro está em R1. A.3 gettimeofday A chamada de sistema gettimeofday recebe dois ponteiros como parâmetros. Ignore o segundo fornecendo sempre o valor zero no registrador, pois este é usado para obter informações de fuso horário que estão em desuso nos sistemas mais modernos, e que não são interessantes para este trabalho. O primeiro parâmetro, em R0, contém um ponteiro para uma estrutura do tipo timeval 3. Essa estrutura contém apenas dois inteiros, tv_sec e tv_usec. A tarefa dessa syscall é atribuir valores a esses dois inteiros utilizando o ponteiro para a estrutura. O primeiro é o número de segundos contados no sistema desde a data 00:00:00, primeiro de janeiro de O segundo é o valor restante de microssegundos. Entretanto, você pode ignorar o segundo valor, pois não será usado neste trabalho. A ideia principal é que você mantenha um relógio interno, movido pelo dispositivo GPT, e que o resultado desse relógio seja obtido com a chamada de sistema gettimeofday e alterado a qualquer hora pelo usuário com a chamada de sistema settimeofday. Você irá criar um relógio baseado nas interrupções do GPT, ou seja, como no laboratório 10. A cada interrupção, você irá interpretar como se tivesse passado 1 segundo. Importante: Para implementar o conceito de tempo no seu sistema, você deverá ter um inteiro na memória que é incrementado a cada interrupção do GPT. A interrupção do GPT sinalizará a passagem de um segundo. Utilize o endereço Esta posição de memória será olhada para verificar que o trabalho implementa corretamente o contador de tempo. 3 Consulte man 2 gettimeofday. 4

5 A.4 settimeofday Essa chamada de sistema recebe os mesmos parâmetros da chamada de sistema gettimeofday. Entretanto, esses ponteiros são usados para ler (ao invés de escrever) valores para configurar um novo valor para o relógio interno do sistema. Ignore o segundo parâmetro (R1) que corresponde a fuso horário e ignore o número de microssegundos. A.5 Testando seu código usuário Se você decidir implementar primeiro o programa de usuário que utiliza as chamadas de sistema para criar o aplicativo de relógio por linha de comando, você pode testá-lo em um sistema operacional real POSIX para ARM, como o Linux. Você pode testar este código diretamente na placa, via SSH. Para isso, monte o seu programa usuário e ligue-o como no laboratório 11: -- na placa -- $ gcc -march=armv5 -marm -fno-stack-protector -c principal.c -o principal.o $ as syscalls.s -o syscalls.o $ ld principal.o syscalls.o -o programa $./programa A primeira linha chama um compilador C para transformar seu código C em um objeto (arquivo principal.o). Este arquivo já contém instruções montadas, mas não é um executável ainda pois contém referências para símbolos não definidos. De maneira similar, a segunda linha chama um montador ARM para transformar o código em linguagem de montagem com o trecho que realiza a chamada para syscalls em outro arquivo objeto (arquivo syscalls.o). Finalmente, a terceira linha chama o ligador, que une os dois arquivos objeto em um mesmo arquivo e ao mesmo tempo resolve referências de um objeto para o outro, como por exemplo a chamada de funções que ocorre em principal.c para funções definidas em syscalls.s. O resultado é um aplicativo de usuário (código que roda no modo usuário do processador, sem privilégios e que recorre a syscalls para realizar tarefas). A última linha do código acima instrui o shell Linux para executar este aplicativo - qualquer chamada de sistema realizada por este código, então, será atendida pelo Linux sobre o qual o programa está executando. Note que o segundo passo deste trabalho é substituir o código do Linux pelo seu próprio código de sistema. Você irá implementar as abstrações por trás das chamadas de sistemas comunicando-se diretamente com o hardware. Por esse motivo, não poderá testar mais na placa real, pois você usar seu próprio código no lugar do sistema operacional Linux. O único modo de prosseguir o trabalho a partir deste ponto é utilizando o simulador. Você pode, entretando, desenvolver o programa usuário na placa e depois rodar seu programa usuário no seu sistema. Mas lembre-se, é importante não utilizar bibliotecas, pois se assim o fizer, seu programa não irá funcionar no seu sistema operacional limitado. A.6 Testando seu código supervisor O único modo de testar o código supervisor (de sistema) é utilizando o simulador. Você deve especificar o código de sistema a carregar com o parâmetro --load-sys= e especificar o código de usuário (o mesmo que também roda na placa como um aplicativo independente) com o parâmetro --load=. O código de sistema deve ser ligado com a opção --Ttext=0 para que o código seja montado a partir do endereço Se você não especificar esta opção, o ligador irá colocar seu código no endereço e, dessa forma, seu sistema não irá executar, pois o processador, assim que ligado, começa sempre a executar a instrução que está no endereço Já o código de usuário não precisa ter seu endereço alterado: ele deve iniciar no endereço padrão escolhido pelo ligador, que é sempre para o ARM. Após a inicialização do sistema, faça o processador mudar para o modo USER e salte para o código de usuário, que está na posição

6 Atenção: Comece seu trabalho a partir do código esqueleto em rafaelauler/mc404/trab3.tar.bz2. Descomprima este código utilizando o comando tar -xjvf trab3.tar.bz2. Nesta estrutura, há duas pastas separadas, uma para que você trabalhe no código de sistema e outra para que trabalhe no código de usuário, cada uma com um Makefile diferente. Você pode e deve alterar os Makefiles, por exemplo, para usar um compilador C, no caso do código de usuário. Exemplo de uso do simulador: $ arm-sim --load=programa --load-sys=knrl -enable-gdb Um detalhe importante é o de que se você fazer uso do depurador gdb, você deve escolher ou o aplicativo ou o código de sistema como parâmetro: $ armv5e-elf-gdb programa Não é possível carregar o código dos dois ao mesmo tempo, apesar do simulador fazer isso. Por esse motivo, recomenda-se que você desenvolva separadamente o seu código de usuário como um programa normal, na placa ARM, e depois faça seu sistema ser capaz de servir o seu aplicativo para que ele funcione corretamente. Atenção: A syscall settimeofday não irá funcionar na placa, pois para mudar o relógio da placa você precisa rodar seu aplicativo com privilégios de superusuário, já que essa é uma tarefa do administrador do Linux. Você só poderá testar esta syscall no simulador rodando seu próprio sistema. B Implementando as chamadas de sistema read e write: como se comunicar com a UART A UART possui um datasheet intimidador de mais de 70 páginas. Não se preocupe, você só irá utilizar o datasheet para consultar os endereços na memória de cada registrador da UART. Quando for fazer isso, lembre-se que o a plataforma imx (da placa que está conectada na rede do IC e que o simulador também reproduz fielmente) possui 4 UARTs. Pegue o endereço da primeira UART, indicada no datasheet como UART1. Sabendo traduzir os endereços dos registradores, para ligar a UART, veja um exemplo de código de inicialização seguindo os passos da seção do datasheet. Contudo, apenas faça o oitavo passo caso vá transferir e receber dados via interrupções. Caso contrário, deixe o registrador UCR1 com o valor 1 (apenas o bit UART ENABLE habilitado). A seguir, será explicado como transferir e receber dados por polling, isto é, sem utilizar interrupções. B.1 Recepção de dados Verifique se o bit RDR (receiver data ready), isto é, o bit 0 do registrador UART STATUS REGISTER 2 (UART1_USR2), está definido como 1. Caso positivo, isto indica que pelo menos 1 caractere está esperando para ser lido na fila de recepção (RX FIFO). Essa fila possui 32 posições e armazena os caracteres recebidos. Quando uma leitura é realizada pelo programa, 1 caractere é removido da fila. Caso a fila fique cheia e o programa não leia os caracteres pendentes para liberar espaço, a UART sinaliza o produtor de dados que irá começar a descartar dados, pois não há mais espaço na fila de recepção. É de responsabilidade de quem esteja transmitindo os dados, então, respeitar isso e parar de enviar dados. Essa é chamada forma de controle de fluxo via hardware. Para ler o próximo caractere na fila RX FIFO, basta realizar uma leitura no registrador UART1_URXD. Ao ler este registrador, você irá receber, nos primeiros 8 bits, o caractere lido. Ao mesmo tempo, a UART irá decrementar a contagem de elementos na fila de leitura. Caso essa contagem chegue a zero, a flag RDR é automaticamente desligada (vai para 0). Portanto, uma forma de realizar leitura da UART é implementar um laço que lê byte por byte, realizando sucessivas leituras em UART1 URXD sempre que a flag RDR estiver avisando que há bytes para serem lidos. 6

7 Uma condição de parada do laço pode ser, por exemplo, se o número de bytes lidos já alcançou o número solicitado pelo usuário que invocou a chamada de sistema read. B.2 Transmissão de dados Verifique se o bit TRDY (transmitter ready), isto é, o bit 13 do registrador UART STATUS REGISTER 1 (UART1_USR1), está definido como 1. Caso positivo, isto indica que a fila de transmissão (TX FIFO) está abaixo de um nível de segurança pré-configurado (quando você configurou a UART seguindo os passos do datasheet, ou seja, você pode enviar um byte para transmissão sem correr o risco de perder o dado por fila cheia. Essa fila possui 32 posições e armazena os caracteres que estão pendentes para serem enviados. Quando um byte é transmitido, um caractere é removido da fila. Para escrever um caractere na fila TX FIFO e escaloná-lo para ser transmitido, basta realizar uma escrita no registrador UART1_UTXD. Ao escrever neste registrador, o dado vai para a fila TX FIFO. Caso a fila fique acima de um determinado nível, correndo o risco de ficar cheia, o bit TRDY é automaticamente desligado (vai para 0). Portanto, uma forma de realizar escrita pela UART é implementar um laço que escreve byte por byte, realizando sucessivas escritas em UART1 UTXD sempre que a flag TRDY estiver avisando que o dispositivo pode receber mais um byte. A condição de parada do laço será se o número de bytes escritos já alcançou o número solicitado pelo usuário da chamada de sistema write. B.3 Dúvidas? Consulte o FAQ em rafaelauler/mc404/faq.html. 7