• dificuldade em criar sistemas embarcados: como disparar sw e hw juntos?
• custo do hw
• o conhecimento de hw se desgasta muito mais rapido do que o sw.
• como criar um aparelho com um sensor novo via hw?

-- criar o sensor
-- conectar o sensor em algum barramento: spi, i2c.
-- criar um driver, tratar da interrupcao.

• como emular o aparelho com o sensor novo?

-- qemu com uma placa bem testada como a versatilepb
-- emular o dispositivo na gpio
-- criar o driver para o linux tratando das interrupcoes.

• objetivo: cada equipe deverah criar um dispositivo simples (ex: um botao) ligando-se aa placa versatilepb

• continuar os projetos na disciplina de sistemas embarcados.

• pouca documentacao.
• como o qemu funciona?
• como um timer e um processador podem estar rodando ao mesmo tempo?
• como algum periferico eh emulado como uma placa de rede, ou o teclado?
• quando a placa versatile eh emulada, como o linux pode estar vendo um teclado na placa, ou como pode estar se conectando via tty?
• como o qemu pode receber dispositivos do host?
• eh possivel gerar um periferico como um processo que se comunica com o qemu via um socket?
• como o qemu pode emular um periferico num barramento como o spi ou o i2c?
• como podemos fazer o perferico gerar uma interrupcao? (ou como conectar o periferico na contralora de interrupcoes?).

pretendo coletar as respostas no blog ARM Linux Lab.

• achar o maximo de documentacao sobre "qemu internals".
• compilar e rodar o qemu na maquina.
• monitorar como o qemu colocando mensagens
• estudar como o qemu roda o processador e perifericos (ex: timer) juntos.
• estudar e rodar algum projeto no github que envolva criacao de perifericos no qemu.
• desenvolver o proprio projeto.

• 14:00 - 15:50H - qemu.
• 15:50 - 17:40 - projeto.

Q - trabalho com o qemu I - implementacao do projeto. Final = (Q+I)/2

Pontualidade

• 1 ponto a menos a cada 15 minutos de atraso.
• avaliacao a cada aula; apresentacao dos resultados a partir das 15:30H.

Livro que usamos no ano passado: Derek Molloy-Exploring Raspberry Pi_ Interfacing to the Real World with Embedded Linux-Wiley (2016).pdf

Livros: Artem Kotovsky - How to Develop Embedded Software Using The QEMU Machine Emulator-Apriorit Inc. (procure na internet) Robert Warnke, Thomas Ritzau - QEMU -BoD (2009)

Estudo do qemu

• https://ieeexplore.ieee.org/document/8117087
• https://www.qemu.org/2018/02/09/understanding-qemu-devices/
• http://codelectron.com/how-to-setup-virtual-spi-in-linux/
• http://blog.vmsplice.net/2011/03/qemu-internals-big-picture-overview.html
• https://www.linaro.org/blog/running-64bit-android-l-qemu/

Sobre como funciona o qemu: http://blog.vmsplice.net/2011/03/qemu-internals-overall-architecture-and.html

Como adicionar um dispositivo

• https://stackoverflow.com/questions/28315265/how-to-add-a-new-device-in-qemu-source-code
• https://github.com/grandemk/qemu_devices
• https://www.ispras.ru/conf/2017/pdf/Efimov.pdf
• https://github.com/sheepdog/qemu/blob/master/hw/arm/versatilepb.c

Para hoje:

• estudar: https://ieeexplore.ieee.org/document/8117087
• apresentacao do que foi entendido.

arm-none-eabi-gdb program.elf 
/home/professor/Downloads/qemu-4.1.0/arm-softmmu/qemu-system-arm -M versatilepb -m 128M -nographic -s -S -kernel program.bin

Obs: no ubuntu 18.4 nao existe arm-none-eabi-gdb, use gdb-multiarch

relacionar https://ieeexplore.ieee.org/document/8117087 com o codigo do qemu.

• quando se escreve em um registrador do timer, qual eh a funcao helper que o qemu dispara?

O timer eh o sp804 e tratado em: file:///home/professor/Downloads/qemu-4.1.0/hw/timer/arm_timer.c

• com o qemu compilado podemos estudah-lo. O objetivo da aula eh observar como o qemu lida com o periferico timer na placa versatilepb. O ideal eh usar o gdb para entender o qemu; mas o grande objetivo da aula de hoje eh entender a interface do qemu com o timer.

• Coloquem um breakpoint em arm-none-eabi-gdb de tal forma a parar quando vamos escrever algo no timer. Exemplo:

Em ../meuscursos/embed/e10/irq.s existe a rotina timer_init que faz a inicializacao do timer. A instrucao

TIMER0C: .word 0x101E2008 @timer 0 control register
    (...)
    LDR r0, TIMER0C
    LDR r1, [r0]
    MOV r1, #0xA0 @enable timer module
    STR r1, [r0]

Quando se faz STR no TIMER0C temos que a funcao arm_timerwrite deve ser acionada.

• Na funcao timer do arquivo file:///home/professor/Downloads/qemu-4.1.0/hw/timer/arm_timer.c , coloquem um breakpoint em sp804_write e arm_timerwrite

Observem todas as funcoes chamadas quando se escreve no timer. Voces devem obter algo como:

Thread 3 "qemu-system-arm" hit Breakpoint 1, arm_timer_write (opaque=0x555556b3e9e0, offset=8, value=160) at hw/timer/arm_timer.c:96
96	{
(gdb) bt
#0  arm_timer_write (opaque=0x555556b3e9e0, offset=8, value=160) at hw/timer/arm_timer.c:96
#1  0x000055555588dfc2 in memory_region_write_accessor (mr=0x555556bcd480, addr=8, value=<optimized out>, size=4, shift=<optimized out>, mask=<optimized out>, attrs=...)
    at /home/professor/Downloads/qemu-4.1.0/memory.c:508
#2  0x000055555588bacd in access_with_adjusted_size (addr=addr@entry=8, value=value@entry=0x7ffff3065318, size=size@entry=4, access_size_min=<optimized out>, access_size_max=<optimized out>, 
    access_fn=0x55555588df40 <memory_region_write_accessor>, mr=0x555556bcd480, attrs=...) at /home/professor/Downloads/qemu-4.1.0/memory.c:574
#3  0x000055555589062b in memory_region_dispatch_write (mr=mr@entry=0x555556bcd480, addr=addr@entry=8, data=data@entry=160, size=size@entry=4, attrs=...)
    at /home/professor/Downloads/qemu-4.1.0/memory.c:1509
#4  0x000055555589e83c in io_writex (env=env@entry=0x5555568010c0, iotlbentry=0x555556809510, mmu_idx=mmu_idx@entry=1, val=val@entry=160, addr=addr@entry=270409736, 
    retaddr=retaddr@entry=140737270678637, size=4) at /home/professor/Downloads/qemu-4.1.0/accel/tcg/cputlb.c:950
#5  0x00005555558a3d1c in store_helper (big_endian=false, size=4, retaddr=<optimized out>, oi=33, val=160, addr=<optimized out>, env=0x5555568010c0)
    at /home/professor/Downloads/qemu-4.1.0/accel/tcg/cputlb.c:1556
#6  helper_le_stl_mmu (env=0x5555568010c0, addr=<optimized out>, val=160, oi=33, retaddr=140737270678637) at /home/professor/Downloads/qemu-4.1.0/accel/tcg/cputlb.c:1660
#7  0x00007ffff306846d in code_gen_buffer ()
#8  0x00005555558ba0d1 in cpu_tb_exec (itb=<optimized out>, cpu=0x7ffff3068380 <code_gen_buffer+4950>) at /home/professor/Downloads/qemu-4.1.0/accel/tcg/cpu-exec.c:173
#9  cpu_loop_exec_tb (tb_exit=<synthetic pointer>, last_tb=<synthetic pointer>, tb=<optimized out>, cpu=0x7ffff3068380 <code_gen_buffer+4950>)
    at /home/professor/Downloads/qemu-4.1.0/accel/tcg/cpu-exec.c:621
#10 cpu_exec (cpu=cpu@entry=0x5555567f7fd0) at /home/professor/Downloads/qemu-4.1.0/accel/tcg/cpu-exec.c:732
#11 0x00005555558811ff in tcg_cpu_exec (cpu=0x5555567f7fd0) at /home/professor/Downloads/qemu-4.1.0/cpus.c:1435
#12 0x0000555555883340 in qemu_tcg_cpu_thread_fn (arg=arg@entry=0x5555567f7fd0) at /home/professor/Downloads/qemu-4.1.0/cpus.c:1743
#13 0x0000555555ce9936 in qemu_thread_start (args=<optimized out>) at util/qemu-thread-posix.c:502
#14 0x00007ffff5ea96ba in start_thread (arg=0x7ffff3066700) at pthread_create.c:333
#15 0x00007ffff5bdf41d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:109
(gdb)

Obviamente se escrevessemos na posicao 0x1000 nenhum periferico seria ativado. Como o qemu sabe que eh necessario chamar a funcao arm_timerwrite ao se escrever em certo endereco? Como o timer foi alocado em certos enderecos na placa versatilepb?

Para isso, para mostrar todas as ocorrencias de "versat" no codigo:

~/Downloads/qemu-4.1.0/hw/arm$ grep -rl versat .

Dentre varias ocorrencias, o arquivo: file:///home/professor/Downloads/qemu-4.1.0/hw/arm/versatilepb.c contem a descricao do hardware da placa versatilepb

Em particular o timer estah como:

sysbus_create_simple("sp804", 0x101e2000, pic[4]);
sysbus_create_simple("sp804", 0x101e3000, pic[5]);
/* 0x101e2000 Timer 0/1.  */
/* 0x101e3000 Timer 2/3.  */

Assim, para se criar um terceiro timer, em um outro endereco poderiamos fazer algo como (observe que nao eh nessa posicao de fato):

#include "hw/sysbus.h"
(...)
sysbus_create_simple("sp804", 0x101e?000, pic[4]); # para usar a mesma interrupcao do timer 0/1

Observando file:///home/professor/Downloads/qemu-4.1.0/include/hw/sysbus.h vemos:

static inline DeviceState *sysbus_create_simple(const char *name,
                                              hwaddr addr,
                                              qemu_irq irq)
{
    return sysbus_create_varargs(name, addr, irq, NULL);
}

sysbus_{createvarargs} estah declarado em: file:///home/professor/Downloads/qemu-4.1.0/hw/core/sysbus.c e cria o device atraves de:

dev = qdev_create(NULL, name);
s = SYS_BUS_DEVICE(dev);

A funcao SYS_BUSDEVICE estah definida em file:///home/professor/Downloads/qemu-4.1.0/include/hw/sysbus.h como:

#define SYS_BUS_DEVICE(obj) \
     OBJECT_CHECK(SysBusDevice, (obj), TYPE_SYS_BUS_DEVICE)

Uma ideia de como se conecta um cria um dispositivo no qemu estah em: https://www.linux-kvm.org/images/f/fe/2010-forum-armbru-qdev.pdf http://events17.linuxfoundation.org/sites/events/files/slides/ossj-2017.pdf

Vamos tentar criar um dispositivo "sp805" que eh apenas uma copia do "sp804". Vamos tentar colocar esse "novo" sp805 para rodar da seguinte forma:

#include "hw/sysbus.h"
(...)
sysbus_create_simple("sp805", 0x101e?000, pic[4]); # para usar a mesma interrupcao do timer 0/1

Para isso vamos criar um novo tipo de timer sp805 em: file:///home/professor/Downloads/qemu-4.1.0/hw/timer/arm_timer.c

static void arm_timer_register_types(void)
{
    type_register_static(&icp_pit_info);
    type_register_static(&sp804_info);
    type_register_static(&sp805_info);
}
... sintam-se a vontade de deixar algo do sp804 no sp805
static const TypeInfo sp805_info = {
    .name          = TYPE_SP805,
    .parent        = TYPE_SYS_BUS_DEVICE,
    .instance_size = sizeof(SP804State),
    .instance_init = sp805_init,
    .class_init    = sp804_class_init,
};
...

static void sp805_init(Object *obj)
{
    SP804State *s = SP804(obj); <-- alterar
    SysBusDevice *sbd = SYS_BUS_DEVICE(obj);

    sysbus_init_irq(sbd, &s->irq);
    memory_region_init_io(&s->iomem, obj, &sp805_ops, s,   # <--- alterando para sp805_ops
                          "sp804", 0x1000);
    sysbus_init_mmio(sbd, &s->iomem);
}


... funcoes que leem e escrevem, se quiser alterar sp804 para uma nova funcao
static const MemoryRegionOps sp805_ops = {
    .read = sp804_read,
    .write = sp805_write,
    .endianness = DEVICE_NATIVE_ENDIAN,
};

Altere o programa que gera as interrupcoes de forma que no loop principal, se imprima continuamente o valor do timer. Observar se esse valor do timer vai sendo modificado dentro do loop principal. file:///home/professor/casa/meuscursos/embed/e10/handler.c file:///home/professor/casa/meuscursos/embed/e10/handler_manual.s file:///home/professor/casa/meuscursos/embed/e10/irq.s Observe a struct em file:///home/professor/Downloads/qemu-4.1.0/hw/timer/arm_timer.c

typedef struct {
    ptimer_state *timer;
    uint32_t control;
    uint32_t limit;
    int freq;
    int int_level;
    qemu_irq irq;
} arm_timer_state;

O que vc. acha que significa cada elemento da struct? Olhe o codigo file:///home/professor/Downloads/qemu-4.1.0/hw/timer/arm_timer.c . Olhando o codigo, o valor "timer" corresponde ao valor do contador. No entanto, nao existe no codigo nenhum lugar onde esse campo da struct eh decrementado.

static uint32_t arm_timer_read(void *opaque, hwaddr offset)
{
    (...)
    case 1: /* TimerValue */
        return ptimer_get_count(s->timer);

Portanto, o valor do timer (s->timer) estah sendo obtido atraves de ptimer_getcount e nao diretamente. Coloque um breakpoint ao se fazer a leitura do timer. Faca bt (backtrace) para observar quais funcoes estao envolvidas em quais arquivos.

 ptimer_get_count (s=0x555556bce3d0) at hw/core/ptimer.c:172
#1  0x0000555555b4dda8 in arm_timer_read (opaque=<optimized out>, offset=<optimized out>) at hw/timer/arm_timer.c:60
#2  0x0000555555b4debc in sp804_read (opaque=<optimized out>, offset=<optimized out>, size=<optimized out>)
    at hw/timer/arm_timer.c:219
#3  0x000055555588e21d in memory_region_read_accessor (mr=0x555556bcd480, addr=4, value=0x7ffff30653e0, size=4, shift=0, 
    mask=4294967295, attrs=...) at /home/professor/Downloads/qemu-4.1.0/memory.c:444
#4  0x000055555588bacd in access_with_adjusted_size (addr=addr@entry=4, value=value@entry=0x7ffff30653e0, size=size@entry=4, 
    access_size_min=<optimized out>, access_size_max=<optimized out>, access_fn=0x55555588e1e0 <memory_region_read_accessor>, 
    mr=0x555556bcd480, attrs=...) at /home/professor/Downloads/qemu-4.1.0/memory.c:574
#5  0x0000555555890450 in memory_region_dispatch_read1 (attrs=..., size=4, pval=0x7ffff30653e0, addr=4, mr=0x555556bcd480)
    at /home/professor/Downloads/qemu-4.1.0/memory.c:1431
#6  memory_region_dispatch_read (mr=mr@entry=0x555556bcd480, addr=addr@entry=4, pval=pval@entry=0x7ffff30653e0, size=size@entry=4, 
    attrs=...) at /home/professor/Downloads/qemu-4.1.0/memory.c:1452
#7  0x000055555589e185 in io_readx (env=env@entry=0x5555568010c0, iotlbentry=0x555556809510, mmu_idx=mmu_idx@entry=1, 
    addr=addr@entry=270409732, retaddr=retaddr@entry=140737270682333, access_type=access_type@entry=MMU_DATA_LOAD, size=4)
    at /home/professor/Downloads/qemu-4.1.0/accel/tcg/cputlb.c:909
#8  0x000055555589fb3b in load_helper (full_load=0x55555589f8a0 <full_le_ldul_mmu>, code_read=false, big_endian=false, size=4, 
    retaddr=<optimized out>, oi=<optimized out>, addr=<optimized out>, env=0x5555568010c0)
    at /home/professor/Downloads/qemu-4.1.0/accel/tcg/cputlb.c:1308
#9  full_le_ldul_mmu (env=0x5555568010c0, addr=<optimized out>, oi=<optimized out>, retaddr=140737270682333)
    at /home/professor/Downloads/qemu-4.1.0/accel/tcg/cputlb.c:1423
#10 0x00007ffff3069340 in code_gen_buffer ()
#11 0x00005555558ba0d1 in cpu_tb_exec (itb=<optimized out>, cpu=0x7ffff3069280 <code_gen_buffer+8790>)
    at /home/professor/Downloads/qemu-4.1.0/accel/tcg/cpu-exec.c:173
#12 cpu_loop_exec_tb (tb_exit=<synthetic pointer>, last_tb=<synthetic pointer>, tb=<optimized out>, 
    cpu=0x7ffff3069280 <code_gen_buffer+8790>) at /home/professor/Downloads/qemu-4.1.0/accel/tcg/cpu-exec.c:621
#13 cpu_exec (cpu=cpu@entry=0x5555567f7fd0) at /home/professor/Downloads/qemu-4.1.0/accel/tcg/cpu-exec.c:732
#14 0x00005555558811ff in tcg_cpu_exec (cpu=0x5555567f7fd0) at /home/professor/Downloads/qemu-4.1.0/cpus.c:1435
#15 0x0000555555883340 in qemu_tcg_cpu_thread_fn (arg=arg@entry=0x5555567f7fd0) at /home/professor/Downloads/qemu-4.1.0/cpus.c:1743
#16 0x0000555555ce9936 in qemu_thread_start (args=<optimized out>) at util/qemu-thread-posix.c:502
#17 0x00007ffff5ea96ba in start_thread (arg=0x7ffff3066700) at pthread_create.c:333
#18 0x00007ffff5bdf41d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:109

#0  arm_timer_tick (opaque=0x555556b3e9e0) at hw/timer/arm_timer.c:147
#1  0x0000555555ce3cee in aio_bh_call (bh=0x555556bce3a0) at util/async.c:89
#2  aio_bh_poll (ctx=ctx@entry=0x5555567da670) at util/async.c:117
#3  0x0000555555ce7200 in aio_dispatch (ctx=0x5555567da670) at util/aio-posix.c:459
#4  0x0000555555ce3bce in aio_ctx_dispatch (source=<optimized out>, callback=<optimized out>, user_data=<optimized out>)
    at util/async.c:260
#5  0x00007ffff6bb2197 in g_main_context_dispatch () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#6  0x0000555555ce6291 in glib_pollfds_poll () at util/main-loop.c:218
#7  os_host_main_loop_wait (timeout=<optimized out>) at util/main-loop.c:241
#8  main_loop_wait (nonblocking=<optimized out>) at util/main-loop.c:517
#9  0x0000555555a08235 in main_loop () at vl.c:1791
#10 0x0000555555835cb6 in main (argc=<optimized out>, argv=<optimized out>, envp=<optimized out>) at vl.c:4473

file:///home/professor/Downloads/qemu-4.1.0/util/async.c

file:///home/professor/Downloads/qemu-4.1.0/util/main-loop.c

A funcao ptimer_getcount estah em (vide debug acima): file:///home/professor/Downloads/qemu-4.1.0/hw/core/ptimer.c Ao observar o codigo de ptimer_getcount observamos :

int64_t now = qemu_clock_get_ns(QEMU_CLOCK_VIRTUAL);

onde a variavel now deve indicar o momento atual. Colocando um breakpoint em qemu_clockgetns caimos em: file:///home/professor/Downloads/qemu-4.1.0/util/qemu-timer.c O valor do timer provem de:

QEMUTimerListGroup main_loop_tlg;

qemu_clock_run_timers

Procurem localizar o codigo em C que apresenta quando o timer eh decrementado.

static arm_timer_state *arm_timer_init(uint32_t freq)
 ... bh = qemu_bh_new(arm_timer_tick, s);

O qemu nao atualiza continuamente o tick do timer a fim de evitar muito processamento. Ele usa o relogio da maquina e faz uma aproximacao do valor do tick do timer. Se dentro dessa aproximacao, houver uma interrupcao do timer; entao ela eh gerada.

crie uma porta de entrada no sp805. O codigo deve ler um numero (zero ou um) de um certo arquivo. crie um pequeno codigo assembly que continuamente le de essa porta de entrada e imprime zero ou um.

Vamos criar, futuramente, uma forma do usuario criar um periferico virtual que gera uma interrupcao. vamos criar um signal handler no qemu de forma que geremos uma interrupcao para o nosso periferico virtual. Para isso:

http://www.pcs.usp.br/~jkinoshi/2019/Exp8_revisada_17_10_19.doc testar o driver no ubuntu.

Colocar o trabalho da equipe do Shibata, fase 3, rodar dentro docker: http://linux-kernel-lab.blogspot.com/2018/06/blocking-device.html

Fazer o mesmo trabalho da equipe do Shibata fora do docker. Observem: Em: file:///home/professor/Downloads/pcs3746-sistemas-operacionais/1/docker/Dockerfile temos os comandos para subir o ubuntu 16.4 e instalar as toolchains necessarias para compilar o linux :

apt-get update && apt-get install --no-install-recommends -y bc binutils-arm-linux-gnueabi \
    build-essential cpio gcc-arm-linux-gnueabi gdb-arm-none-eabi libc6-dev-armel-cross \
    libelf-dev locales qemu-system-arm sudo && \
    rm -rf /var/lib/apt/lists/*

Em:

file:///home/professor/Downloads/pcs3746-sistemas-operacionais/1/docker/default_cmd.sh temos o comando para compilar o linux usando o toolchain instalada pelo Dockerfile e ativar o qemu.

Alem disso, para a fase 3, a equipe do Shibata criou um init para disparar uma shell, o "busybox sh".

Veja como a equipe do Shibata compilou o driver e faca de forma semelhante.

Usando o qemu modificado com o sp805, alterar o driver simples para acender um led.

teste o driver fazendo algo como:
echo "1" > /dev/led # acende led
echo "0" > /dev/led

https://www.youtube.com/watch?v=sX5vAPUDJVU http://events17.linuxfoundation.org/sites/events/files/slides/Improving%20the%20QEMU%20Event%20Loop%20-%203.pdf

• entender como funciona o loop principal do qemu
• estudar como as teclas sao enviadas para o driver do linux observando o loop principal. A placa versatile pode receber dados do teclado da maquina hospedeira atraves da serial ou do teclado (ver arquivo de versatilepb.c). Quando o linux estah usando o busybox shell deve estar vendo dados vindos pela serial.

A transparencia: http://events17.linuxfoundation.org/sites/events/files/slides/Improving%20the%20QEMU%20Event%20Loop%20-%203.pdf mostra 3 fases no loop principal: prepare, poll, dispatch.

Ao teclar supomos (nao tenho certeza) que nas fases: 1-prepare: o evento eh dectado. Como o evento foi detectado? Por epoll_wait, epoll_pwait, select, pselect? 2-poll: o qemu escolhe dentre varios eventos qual vai ser tratado. Supondo que tivesse ocorrido o estouro de um timer junto com o aperto de uma tecla, qual seria tratado primeiro? 3-dispatch: o qemu deve gerar uma interrupcao para o verstile informando de que houve a interrupcao.

• gerar um relatorio informando o que foi descoberto sobre o funcionamento do qemu.

Se entendermos bem esse loop principal, acreditamos que poderemos criar um dispositivo no qemu que gere interrupcoes. Exemplo: o teclado poderia ser visto pelo versatile apenas como um botao que gera as interrupcoes (um grande desperdicio de teclado); ou o qemu poderia ser modificado para quando teclassemos algo como Control-Alt-1, entao o botao emulado geraria a interrupcao.

• Vamos utilizar o teclado no metal cru (bare metal) usando o post: https://balau82.wordpress.com/2010/12/16/using-newlib-in-arm-bare-metal-programs/

• A transparencia mostra o nome de funcoes nas fases prepare, poll e dispatch. Colocar printfs.
• entenda a system call epoll fazendo :

https://medium.com/@copyconstruct/the-method-to-epolls-madness-d9d2d6378642

https://suchprogramming.com/epoll-in-3-easy-steps/

• pesquisei epoll_wait no codigo do qemu. Existem diversas ocorrencias principalmente para se definir numero de system call. Assim, uma forma de pararmos o gdb quando se fizer uma system call eh https://reverseengineering.stackexchange.com/questions/6835/setting-a-breakpoint-at-system-call:

Verifique se de fato eh o numero 41.

(gdb) catch syscall 41
(gdb) r

• Colocar breakpoints no lugar onde a tecla foi apertada e o qemu detectou. Usando "bt" obervar quais foram as funcoes chamadas, o que deve estar na fase prepare.
• Colocar breakpoints quando o aperto da tecla gerar interrupcoes de teclado para o versatile, o que deve estar na fase dispatch.
• Observar no codigo qual eh a interrupcao gerada pelo teclado para o linux. Qual eh o numero da interrupcao dado pelo qemu?
• do lado do linux: descobrir qual driver eh acionado quando o busybox recebe uma tecla.
• qual rotina de interrupcao eh acionada? colocar um breakpoint quando o driver recebe uma tecla.

• gerar uma interrupcao para o sp805 via teclado, por exemplo, quando o usuario teclar "1".

https://www.xml.com/ldd/chapter/book/ch08.html

• gravar imagem no micro sdcard; De preferencia que cada equipe tenha um micro sdcard.

fig. 6.2 b) Observar a frequencia maxima possivel acendendo e apagando leds.

fig 6.1

fig. 6.5

pg 225

Responda no relatorio:

• Qual o objetivo de resistores internos pull down e pull up? pg 226
• Como verificar se a saida do GPIO eh pulldown ou pullup?
• Para que serve o optocoupler? pg 228
• Pesquise: O que é o sysfs no linux?

• Leia "C++ Control of GPIOs Using sysfs"
• Rode o programa

Responda no relatorio:

• O que o livro fala sobre o linux kernel ser preemptivo? pg 223
• como verificar se o linux kernel eh preemptivo ou nao? Faca testes com sua maquina e a raspberry pi.
• O que faz o cyclictest e o que tem a haver com o kernel ser preemptivo? Veja: http://people.redhat.com/williams/latency-howto/rt-latency-howto.txt
• Rode o cyclictest no raspberry pi3 e em sua maquina normal.

• rode o exemplo de funcao callback pg 237
• posix threads

Responda:

• O que eh o sysfs?
• Como pode ser usado para controlar perifericos na GPIO?

• GPIO visto como memoria, via devmem2
• Estude o item Memory-Based GPIO Control
• rode o codigo /chp06/memoryGPIO/LEDflash.c pg 249

Responda:

• Como o GPIO pode ser acessada em C?
• Mostre exemplos de como isso ocorre em devmem2.
• Crie um onda quadrada com a maior frequencia possivel usando C. Qual o periodo?

• Como usar python para acessar os leds?
• Gere uma onda quadrada o mais rapido possivel usando python. Qual o periodo?

Como usar udev o bit setuid para controlar aplicacoes que usam o GPIO rodando em modo usuario?

Execute o codigo para rodar um exemplo de modulo rodando no ubuntu normal e depois no raspberry.

Se nao fizeram, facam.

Se nao fizeram, facam.

Estudar: http://pradheepshrinivasan.github.io/2015/07/02/Creating-an-simple-sysfs/ Modificar o modulo para contar o numero de vezes que o botao foi pressionado e permitir com que esse valor seja visto no sysfs. Exemplo cat /sys/botao

Alterar o codigo para permitir com que se resete o valor do contador fazendo algo como: echo 0 > /sys/botao

O que sao kobjects? Como eles sao utilizados no driver? O que eh armazenado no kobject que estah no driver? Como o driver apresenta o numero de vezes que o botao eh pressionado em /sys ? Que funcao utiliza? A qual variavel estah "amarrada"?

Construir um driver para um dispositivo de entrada composto de botao e chave. a cada borda de subida do botao, o valor da chave eh lido e armazenado. Na primeira versao, quando o driver eh lido, apenas o valor da ultima posicao da chave eh apresentada. Se nao houve entrada de dados, interrupcao, entao o driver deve ficar bloqueado. Numa segunda versao, ao ler do dispositivo, o driver deve retornar a string de zeros e uns que foi formada. Se nao houver nada vindo do dispositivo, o processo que faz a leitura do driver deve ficar bloqueado numa fila de espera.