Lab. Microprocessadohres

• O professor passou segment.c, segment.h. Gere o arquivo segment.o e execute no kit. Veja que aparece um numero no display. Note que segment.c imprime o numero no main. Ver PASSO-1 da apostila.

A apostila foi feita para se rodar a experiencia na placa evaluator-7t

arm-elf-gcc segment.c –o segment.o

porém, para debugar voce precisa adicionar a opcao -g

arm-elf-gcc -g segment.c –o segment.o

• crie a funcao imprime em segment.c que recebe um numero e coloca esse numero no display. Para isso basta retirar do main a parte pertinente. Compile e teste. Ver PASSO-2 da apostila.
• crie o arquivo imprime.c com a funcao imprime gerada no item anterior. O codigo executavel eh gerado atraves de: arm-elf-gcc -g imprime.c segment.c -o segment.o; teste o codigo gerado. Ver PASSO-3 da apostila.
• compile imprime.c gerando seu objeto: arm-elf-gcc -S impime.c (gerando imprime.s). Refaca o codigo usando imprime.s + segment.c. Teste. Ver PASSO-4 da apostila.

No passo 4, existem duas formas de gerar o arquivo .elf para ser executado na placa:

a) O gcc faz tudo (monta e linka): arm-elf-gcc –g imprime.s segment.c –o segment.o

b) O gcc soh compila:

Para o segment.c e para o imprime.c fazer:

arm-elf-gcc -S segment.c
arm-elf-as -o segment.o segment.s

E depois linkar o segment.o e imprime.o usando arm-elf-ld. Porém utilize a forma a) para evitar problemas com linkar com a biblioteca do ambiente (para uma funcao usada para chamar o main e para o printf).

• Estude o codigo imprime.s.
  Como o numero eh passado como parametro? Como o fp é usado para isso? Isso corresponde ao PASSO-5 da apostila, mas não é necessário fazer esse passo.

  Em uma funcao, os registradores poderiam ser salvos e recuperados chamados assim:

  BL myfunction
  myfunction
             .....
             STMFD sp!, {r4-r10, lr}; guarda os registradores
             .....
             .....
             LDMFD sp!, {r4-r10, pc}; recupera os registradores; o retorno da funcao eh feito colocando lr em pc.
  

  Para entender melhor como funciona a chamada de rotinas, veja: http://infocenter.arm.com%2Fhelp%2Ftopic%2Fcom.arm.doc.ihi0042d%2FIHI0042D_aapcs.pdf Responda: Quais sao os registradores atribuidos a: fp, ip, sp, lr?

  Para que serve o fp? Responda.

  Para que serve o ip? Resposta: Register r12 (IP) may be used by a linker as a scratch register between a routine and any subroutine it calls (for details, see §5.3.1.1, Use of IP by the linker). It can also be used within a routine to hold intermediate values between subroutine calls. Essa resposta eh extremamente confusa, mas eh o que estah escrito em aapcs.pdf. Em: https://stackoverflow.com/questions/16120123/arm-why-do-i-need-to-push-pop-two-registers-at-function-calls temos que a ARM quer o alinhamento de 8 bytes na memoria (para o ARM 64 bits) Isso explica o motivo de se ter um registrador scratch (r12, ip) colocado na pilha - porque do ponto de vista da recursao em si, nao faz sentido…

• Agora que voce conhece imprime.s e imprime.c; altere imprime.c para se colocar codigo assembly dentro do codigo C usando o inline.
  Ver PASSO-6 da apostila. Basicamente voce deve imprimir um numero em imprime.c usando a funcao printf. Depois, observe o imprime.s (gerado pelo compilador de imprime.c) e tire o miolo da funcao imprime em assembly e enxerte no codigo em C.

  Observacao: O compilador gera lables com pontos na frente (ex: .L4). Apenas o compilador deve fazer isso. O código a ser inserido inline não deve ter labels comecando por ponto (ex: L4). Isso evita que o compilador e o usuário criem e usem labels iguais.

  Quando em C, declaramos:

  printf("%d", numero);
  

  O ponteiro para a string "%d" eh passado como parametro para a funcao printf em r0 e numero eh passado em r1. Esse ponteiro eh passado pelo endereco da label .L(numero) e portanto voce nao tem acesso a ele. A fim de ver o ponteiro para string ao misturar C com o assembly declare como variavel global (para facilitar o seu entendimento do codigo gerado):

  char *str = "%d";
  

  e passe o ponteiro para "%d" em r0. Tome cuidado ao fazer isso.

  Se ainda tiver duvidas, veja o assembly de:

  printf(str, numero);
  

  Se voce quiser observar o codigo gerado pelo C rodando como assembly, gere o assembly imprime.s (vindo do imprime.c usando a opcao -S do arm-elf-gcc) e depois faca:

  arm-elf-gcc –g imprime.s segment.c –o segment.o
  

  e debugue segment.o dentro do arm-elf-gdb.

• Observe como o imprime do pre-lab imprime um caracter no codigo assembly (gerado ao compilar .c com -S).
  Utilizando o gdb observe como o fp, ip e sp são utilizados em:

  stmfd sp!, {fp, ip, lr, pc}
  

  e como sao desempilhados em:

  ldmfd sp, {r3, fp, sp, pc}
  

  O arm-elf-gcc estah primeiro passando os parametros por registradores e depois empilhando-os dentro da rotina, por isso os parametros sao acessado via [fp - Numero] pois foram empilhados depois da entrada da rotina que empilhou ip, sp, fp. Supondo que uma funcao tenha 5 parametros, a funcao terah que obrigatoriamente empilhar alguns antes da chamada da rotina e esses parametros vao ser acessados via [fp + Numero]. Verifique colocando 5 parametros na funcao recursiva. Observe como eles sao empilhados e acessados.

  Observe que entre o stmfd e o ldmfd, o sp é alterado; por isso lr eh repassado para o pc.

  O grupo do Lucas,Ricardo,Gabriel,Jonatas enviaram uma foto de como a pilha se comporta quando nas chamadas recursiva em:

  Perguntas: Como o parametro é passado para imprime? Na resposta explique o caso da rotina ter 5 parametros (via registrador e pilha) e da rotina ter poucos parametros (via registrador).

  Como esse parametro é empilhado (isso é necessário em caso de chamadas recursivas)? Como é aberto um espaco na pilha para o parametro de imprime? Onde isso é feito no código?

  Por que se faz fp-16 para acessar o parametro?

  Como esse parametro é desempilhado? Observe que o ip eh repassado para sp e com isso, a alteracao na pilha para abrir o espaco para o parametro de "imprime" é automaticamente refeito.

  • Declare a variavel local "int lixo" na funcao imprime.
    Dentro da funcao recursiva faca, lixo++. Observe o codigo assembly gerado pelo compilador. Responda no relatorio: Como lixo foi referenciado? Como foi aberto espaco na pilha para o lixo? Retire printscreens comparando a pilha sem o uso do int lixo e com o uso de int lixo. Variaveis locais devem ser empilhadas pois caso, a funcao seja recursiva elas fazem parte da recursao.

• Altere imprime em imprime.c para que imprima 7 numeros de 1 a 7 (sem usar assembly no inline).
  Gere o codigo imprime.s. Estude como o fp (frame pointer) eh usado para marcar uma posicao na pilha empilhando parametros e variaveis locais. Apresente no relatorio como a pilha e o fp estao sendo usados. Corresponde ao PASSO-7 da apostila.

  Rode essa versao de imprime no gdb. Retire printscreen antes e depois de cada instrucao que faz alteracao na pilha, em particular:

  stmfd sp!, {fp, ip, lr, pc}
  ldmfd sp, {r3, fp, sp, pc}
  

  Pergunta: Quando imprime chama recursivamente imprime é necessário que o haja um ponteiro para o fp anterior. Como isso é feito? Quando imprime retorna para uma instancia anterior é necessário ue o fp retorne para servir de base para os parametros e variaveis locais anteriores. Explique como isso é feito.

  Ao final da aula, enviar email ao professor contendo o documento gerado com os printscreens. Para ver a pilha no gdb faca x/16 $sp

Antigamente essa toolchain estava mais livre. Agora, estao pedindo que se cadastre para fazer o download. Uma possivel forma de diblar isso é: http://fun-tech.se/stm32/CodeSourceryInstall/ O importante é ter o arquivo arm-none-eabi.bin para fazer a instalacao. Exemplo: http://www.pcs.usp.br/~jkinoshi/2014/arm-2011.03-42-arm-none-eabi.bin

Siga os passos em http://balau82.wordpress.com/2010/02/14/simplest-bare-metal-program-for-arm/ e rode esse programa. O interessante é o startup.s que contém a inicializacao do vetor de interrupcao e faz o codigo rodar a partir da posicao zero.

A fim de imprimir "Hello World" usando o qemu (target remote:1234), vamos usar 2 posts do Balau:

1. http://balau82.wordpress.com/2010/02/28/hello-world-for-bare-metal-arm-using-qemu/
   • usa simulador e imprime string.
2. http://balau82.wordpress.com/2010/02/14/simplest-bare-metal-program-for-arm/ - usa qemu e nao imprime nada.

O que usa o simulador faz um print e o outro que usa o qemu nao printa nada. Por isso vamos rodar basicamente o segundo post, mas fazendo com que se imprima "Hello World" como no primeiro post. Portanto, vamos seguir a risca a forma de rodar o codigo do segundo post passando o print_uart0 do primeiro post para o segundo post.

Observe que em http://balau82.wordpress.com/2010/02/14/simplest-bare-metal-program-for-arm/ o código passa a executar a partir de 0x1000 e não a partir do zero. Isso nao eh o que ocorre quando se faz o boot de uma placa. Provavelmente o Balau fez dessa forma, porque toda placa/simulador vem com um código em eprom que deve ser emulado que corresponde justamente ao código de boot. Nao vamos gerar o codigo segundo esse post. A vantagem desse post eh que ele explica como se faz para imprimir "Hello World".

Observe que em http://balau82.wordpress.com/2010/02/28/hello-world-for-bare-metal-arm-using-qemu/ o codigo estah escrito como acontece em uma placa de verdade, no caso a placa versatile que estah sendo emulada pelo qemu. Use test.ld (o ldscript) e statup.s desse post para fazer o código rodar a partir de 0x0 como acontece em uma placa real. Esse post nao explica como fazer a placa imprimir; por isso precisamos do primeiro post. Observe:

• o startup.s desse post contém o vetor de interrupcao na posicao zero.
• (CUIDADO) No arm..gdb, execute o "load" após o "target" .
• usem o test.ld abaixo que coloca o vetor de interrupcao em zero; nao usem o test.ld que coloca na posicao 0x1000.

ENTRY(_Reset)
SECTIONS
{
 . = 0x0;
 .text : {
 startup.o (INTERRUPT_VECTOR)
 *(.text)
 }
 .data : { *(.data) }
 .bss : { *(.bss COMMON) }
 . = ALIGN(8);
 . = . + 0x1000; /* 4kB of stack memory */
 stack_top = .;

Depois que conseguir imprimir "Hello World" usando o qemu, coloque um breakpoint antes de imprimir o "Hello World" e analise o cpsr. Qual é o modo em que o processador executa? Verifique se está em "Supervisor Mode". Qual é o valor de sp?

Consulte o cpsr em:

• ³ ARM Laboratory Exercises - apostila - http://courses.cs.tamu.edu/rabi/cpsc617/resources/ARM%20Lab%20Mannual.pdf

no capitulo 1, item 1.6.4

Voltando para http://balau82.wordpress.com/2010/02/28/hello-world-for-bare-metal-arm-using-qemu/, crie a funcao Undefined em C que imprime a string "instrucao invalida!" e fique em um loop infinito. Pendure essa funcao no vetor de interrupcao na posicao correspondente a undefined instruction. Observe que dentro do gdb é necessário executar o "load" após o "target".

Toda instrucao corresponde a uma word na memoria. Ex: "MOV R0,R1" corresponde a uma word que pode ser vista como um numero hexadecimal. Alguns numeros fazem sentido (podem ser executados) e outros nao fazem sentido. Por exemplo, a word 0xffffffff eh uma instrucao invalida.

Coloque uma instrucao invalida (0xffffffff) em startup.s (com o startup.s inicializando o codigo em 0x0). Para isso:

Reset_Handler:
        LDR sp, =stack_top
        BL c_entry
        .word 0xffffffff
        B .

Rode o test.elf com a instrucao invalida. Observe se a string eh impressa. Talvez voce tenha visto um lixo sendo impresso ou o qemu tenha travado. Vamos corrigir em seguida.

O ponteiro de pilha r13 no modo undefined nao foi inicializado e isso pode levar a problemas dependendo de como o sp_undefined foi inicializado.

Coloque um breakpoint antes e depois da instrucao invalida e analise o cpsr. Tente observar a mudanca de modo do processador. Conseguiram? Se sim, observe a mudanca no registrador sp (provavelmente o sp no modo Undefined está zerado ou com um valor qualquer. Verifique isso; portanto, qualquer alteracao de pilha nesse modo pode levar a erros com o sp errado). Se nao conseguiram, vejam o Undefined Handler no proximo item e observem a mudanca de modo dentro do Undefined Handler.

Pendure o seguinte Undefined_Handler no vetor de interrupcao em startup.s (certifique-se de que o ld script coloca o codigo em 0x0):

Undefined_Handler:
        LDR sp, =stack_top
        BL undefined

Coloque um breakpoint dentro do Undefined_Handler para observar a mudanca de modo no registrador de status.

Existem 2 erros nesse Undefined_Handler

• a pilha nao deve ser inicializada a cada entrada na rotina de excessao. Veja o proximo item - a pilha no Undefined mode.
• o retorno estah errado.

Quando o processador chaveia de modo, o registrador r13 de um modo não é o mesmo registrador r13 que no outro modo; por isso é necessário inicializar os sp's de todos os modos logo no reset da placa como visto na aula passada. Veja o item 1.6 "The ARM register set" da apostila de ³ e observe se existem outros registradores que variam conforme o modo do processador. Para evitar problema no uso da pilha no modo Undefined, é necessário que Reset_Handler inicialize também o ponteiro de pilha R13_UNDEF (registrador r13 no modo undefined). Inicilize R13_UNDEF com o valor 0x2000 e inicialize o R13_SVC (do supervisor) em 0x1000. Para isso é necessário utilizar a instrucao MSR (Move to Status Register). Usando MSR vah para o modo undefined e altere o R13. Esse R13 no modo undefined (R13_UNDEF) eh diferente do R13 no modo supervisor. Depois volte ao modo supervisor. Descubra o número a ser carregado em MSR (observando principalmente o modo e desabilitando as interrupcoes. Exemplo de como se altera a pilha:

MRS r0, cpsr    @ salvando o modo corrente em R0
MSR cpsr_ctl, #0b11011011 @ alterando o modo para undefined - o SP eh automaticamente chaveado ao chavear o modo
LDR sp, =undefined_stack_top @ a pilha de undefined eh setada 
MSR cpsr, r0 @ volta para o modo anterior 

Pergunta:

• A pilha do Undefined eh inicializada onde?

resposta:

• Reset_Handler pois a pilha do Undefined nao deve ser alterada logo na entrada do Undefined_Handler - o erro eh semelhante a alterar o topo da pilha ao chamar uma funcao!

Refaça o item anterior observando se sp é alterado corretamente na troca de modos.

Crie o undefined handler em assembly de forma que ele salve e recupere os registradores. Veja:

http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0471c/Ciheidgb.html

Explique como o processador volta para o modo anterior ao sair do undefined handler. Rode o programa passo a passo observando os registradores e cpsr sendo salvos e recuperados.

A instrucao:

LDMFD sp!,{R0-R12,pc}^

serah a ultima a ser executada pelo undefined_handler. Ela deve fazer com que o pc continue a partir da instrucao indefinida com o modo anterior (no caso supervisor). Como essa instrucao faz isso?

Responda:

• por que tem um chapeuzinho no final da instrucao? Para que serve isso?
• por que essa instrucao nao salva os registradores r13 e r14?
• se essa eh a primeira instrucao a ser executada, o sp jah deve ter sido inicializado. Quem fez isso? (voce jah deve ter feito isso logo quando a placa eh incializada usando a instrucao MSR para chavear o modo e inicializar o sp).

Antes de escrever a instrucao de store que salva os registradores no comeco do undefined_handler coloque um breakpoint na entrada do undefined_handler e veja onde estah o endereco de retorno. Estah na pilha ou no registrador LR? Agora acerte o undefined_handler com as instrucoes que armazenam e recuperam o estado da pilha com o STMFD.

Agora, em seu codigo faca com que primeiro seja executada a instrucao indefinida e depois imprima o "Hello World" a fim de testar se o retorno do handler de undefined instruction estah funcionando. Apresente isso ao professor.

Embora existam diversos modos no ARM, podemos classificar em usuário e o resto. Quando o ARM comeca a executar está em modo supervisor. Passe para o modo usuário usando MSR e tente voltar do modo usuário para supervisor também usando MSR. O que acontece? Por quê? Refaca a experiencia trocando entre modos dentro do resto (undefined, abort, supervisor, etc.). O que acontece? É possível concluir então que existem dois grandes modos: usuário e supervisor?

TST r0, #0x0010 @verifica se é uma interupção de timer BNE handler_timer @vai para o rotina de tratamento da interupção de timer

A instrucao TST faz o ANDS bit a bit e seta a flag Z (usada pelo BNE) caso o resultado seja zero. O importante eh olhar se o bit estah setado. Se estiver, entao o resultado nao eh zero e por isso eh feito o desvio para o handler_timer.

As pilhas no modo supervisor e no modo IRQ nao sao inicializadas. Com base na experiência da aula passada, ajuste isso; usando MSR. Se voce nao fizer isso, terah problemas graves ao ocorrerem as interrupcoes porque o codigo nao vai retornar para a posicao certa antes da interrupcao.

Observe o codigo

do_irq_interrupt: @Rotina de interrupções IRQ
   STMFD sp!, {r0 - r3, LR}
   @Empilha os registradores
   LDR r0, INTPND @Carrega o registrador de status de interrupção 
   LDR r0, [r0]
   TST r0, #0x0010 @verifica se é uma interupção de timer
   BNE handler_timer @vai para o rotina de tratamento da interupção de timer
   LDMFD sp!, {r0 - r3,lr}
   mov pc, r14
   @retorna

O retorno do IRQ está errado em:

mov pc, r14

r14 é o LR. O LR é automaticamente setado pelo processador ARM quando ocorre a IRQ; porém da seguinte forma: LR = endereco_deretorno + 4 devido ao pipeline. Para resolver isso é necessário fazer retirar 4 de LR.

• Obs - logo ao entrar na rotina de interrupcao, observe para qual instrucao o LR aponta atraves de:

x/i $lr

depois de subtrair 4 de LR, observe novamente

x/i $lr

Agora faz sentido? Isso ocorre por que a propria ARM define assim; meu chute eh pelo pipeline que andou no irq, mas nao andou no undefined (visto na aula passada).

As duas instruções:

LDMFD sp!, {r0 - r3,lr}
mov pc, r14

não recuperam o cpsr anterior. Isso acarreta um problema. O CPSR contém um bit que diz se o processador atende as interrupcoes IRQ ou não. Logo quando ocorre a interrupcao o bit I do cpsr eh zerado para desabilitar que uma interrupcao ocorra dentro de outra. Como o CPSR nao retorna ao valor anterior, ele permanece com as interrupcoes desabilitadas. Com base nessa informacao, altere o código de forma a que a rotina de interrupcao IRQ TERMINE com:

LDMFD sp!,{R0-R12,pc}^

como vimos na aula passada e explicado em http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0471c/Ciheidgb.html

• Obs1: vários alunos trocaram a instrucao LDMFD sp!,{R0-R12,pc}^ por algo como LDMFD sp!,{R0-R12,lr}^ e depois alteraram o pc. Isso nao funciona pois o modo de operacao (e pilhas e backed registers) jah foram alterados. Eh obrigatorio executar LDMFD sp!,{R0-R12,pc}^ para retornar da rotina de interrupcao.
• Obs2: Se sua equipe nao estiver conseguindo retornar da interrupcao rodando LDMFD sp!,{R0-R12,pc}^ observe a pilha. Coloque um breakpoint nessa instrucao e examine como estah a pilha observando o sp. Os valores que estao na pilha correspondem aos que serao colocados nos registradores, e em especial no pc? O retorno deve ser para o loop infinito do programa principal. Esse endereco de retorno estah de fato na pilha? Ao observar o endereco de retorno na pilha, voce pode observar a instrucao que serah executada atraves do comando do debugger x/i ENDERECO.

Alguns alunos consideraram que o mais correto eh usar BLNE ao inves de BNE. Isso nao eh necessario, depende de como handler_timer retorna. A ideia da apostila era retornar para o loop do programa principal diretamente, portanto nao cosideramos isso como um erro da apostila. Contudo, o codigo da apostila nao estah elegante. O melhor eh fazer como no codigo abaixo usando BLNE e fazer handler_timer retornar para quem chamou ao inves de fazer LDMFD.

do_irq_interrupt: @Rotina de interrupções IRQ
   STMFD sp!, {r0 - r3, LR}
   @Empilha os registradores
   LDR r0, INTPND @Carrega o registrador de status de interrupção 
   LDR r0, [r0]
   TST r0, #0x0010 @verifica se é uma interupção de timer
   BLNE handler_timer @vai para o rotina de tratamento da interupção de timer
   LDMFD sp!, {r0 - r3,lr}
   mov pc, r14    @retorna

O código está todo em assembly, mas é possível codificar parte dele em C. Para isso precisamos de seguir diversos passos:

• observe o código de handler_timer:

handler_timer:
        LDR r0, TIMER0X
        MOV r1, #0x0
        STR r1, [r0] @clear timer interrupt

        @ do whatever you want with the timer here

        LDMFD   sp!, {r0 - r3,lr}        
        mov pc, r14

A instrucao mov pc, r14 corresponde ao retorno de do_irqinterrupt (feito de forma errada) e não de handler_timer.

• Altere o código assembly para que handler_timer seja uma rotina estanque chamada em do_irqinterrupt através de:

BLNE handler_timer; ou seja, handler_timer deverá se comportar como uma rotina normal que retorna para quem chamou. Verifique usando o qemu+gdb se voce consegue entrar na rotina handler_timer.

• Crie dois arquivos assembly irq.s e handler.s contendo handler_timer; verifique se funciona, observando duas ou mais interrupcoes de relogio e observe se o sp não está variando a cada chamada - se não está gradativamente empilhando coisas.

Observe que ao linkar, a ordem com que se colocam os objetos irq.o e handler.o eh extremamente importante. Deve-se colocar primeiro o codigo que contenha o vetor de interrupcao.

• Depois recodifique handler_timer em C. Ao fazer isso, declare um pointer em C referente a TIMER0X de forma a colocar o valor zero nessa posicao de memoria a fim de baixar o pedido de interrupcao. Nao eh preciso aproveitar a definicao de TIMER0X do assembly; eh muito mais facil declarar o ponteiro direto em C.

Obs: para exportar o nome handler_timer eh necessario usar .global

• A partir de agora, ao ativar o qemu retire a opcao que "mata" a serial: -serial /dev/null, pois caso contrário, voce não verá os caracteres na tela.
• Misture o codigo dessa experiencia com a da aula passada a fim de que o programa imprima uma vez "Hello World" no program principal, antes mesmo de programar o timer.
• Usando a experiência passada, faça com que o handler_timer em C imprima o digito "1" a cada interrupcao.
• Altere o programa principal para que ele fique em um loop continuamente imprimindo o digito "2" de tempo em tempo (fique em um loop para gastar tempo). Assim, na tela voce deverá ver "1"s e "2"s intercalados. Tente acertar esses tempos de tal forma que se imprima pelo menos 10 "2"s para cada "1".
• O que acontece se nao retirarmos o pedido de interrupcao na rotina que trata a interrupcao? Experimente deixando o programa rodar e explique. A frequencia com que os caracteres sao impressos varia se nao retirarmos o pedido de interrupcao? Ou seja, a relacao entre "2"s e "1"s foi alterada? Explique no relatorio. Rode o programa de uma vez sem breakpoints. Em pelo menos uma equipe, aconteceu do resultado ser diferente rodando passo a passo pois nesse caso, o 1 e 2 eram intercalados enquanto que rodando de uma vez o resultado era o esperado (somente a rotina de interrupcao imprimia).

IMPORTANTE: Nao saia da aula sem apresentar os '1's e '2' sendo impressos.