Posts tagged ‘Linux’

My Sons

That’s my sons:

My sons :)

The left most is  eee.bristot.eti.br: an asus eeePC that’s always with me at my bag. Is a INTEL ATOM n270, I got it because of you battery life, about 6 hour of full work, and your weight, about 1,3Kg with all packages installed and all my music inside ;-)
It’s run Fedora 13 with XFCE Desktop environment.

At the middle is kiron.bristot.eti.br and amd64rt.bristot.eti.br: ok is only the screen, but is an DELL Inspiron 531 with an AMD Athlon 64 X2 3800+.
That’s my desktop and test machine, I run fedora 13 on two installations:

  • The first one is for my desktop machine, where I watch some movies , surf on internet and use to develop some embedded and kernel. The desktop environment is Gnome.
  • The second one is for test real-time Linux kernel and make some applications. It run Fedora 13 with a custom kernel with the last real time patch, the desktop environment is XFCE.

The right most computer is an at91sam9260ek called as at91.bristot.eti.br. Is an Atmel development Kit for at91sam9260 processor (an ARM 926ej-s CPU at 200Mhz).
It run Buildroot Linux with a custom kernel with preempt-rt Linux and I use it to study drivers, kernel, and hardware architecture.

Where wallpaper is possible, is always about MotoGP, preferentially pictures where Valentino Rossi #46 is at 1st position. There is more development kits here, with TI omap3, blackfin and anthers embedded processors, but, these are the computer that i use more :)

LinuxCon 2010: Linux on Real-Time Embedded Systems: Tips and Tools

6:00pm, Tuesday, September 1st
Location: Ballroom 2
Topic: Embedded

By supporting many hardware architectures and reducing the time-to-market, Linux became a frequently choice of operating system to embedded telecommunication devices. However, the vanilla Linux kernel is a soft real-time operating system and needs some patchs, tools an techniques to makes possible your utilization on systems with firm real-time requirements. This presentation shows some tips and tools, collected during the development of embedded telecommunication devices, that transform the vanilla Linux on a operating system able to meet the firm real-time requirements of telecommunications devices, even on small embedded systems. The target audience of this presentation is developers of embedded, real-time and telecommunication systems. It is desired an intermediate knowledge on hardware architecture and solid knowledge in operating systems (IRQ Handling, Scheduling, Real Time).


Daniel Bristot de Oliveira, Intelbras SA

Daniel Bristot de Oliveira is a Computer Scientist and currently is getting master degree in Engineering of Automation and Systems at the Federal University of Santa Catarina, where his research line is real-time operating systems. He is currently a software engineer at Intelbras, a Brazilian telecommunication devices factory, where he is responsible for the OS layer used in the development of embedded systems for telecommunication devices. His key skills are: Customization of the Linux Kernel, device drivers, Real-Time and low level network protocols. He lectured presentations on FISL (2007 and 2009), CONISLI (2006 and 2007), LinuxChix Brazil Meeting and others national and regional events in Brazil.

Muita tecnologia para uma pessoa só

A culpa para eu não ter postado mais é uma só: é muita tecnologia para uma pessoa só!
Nessa vida de acadêmico, profissional e hobbista estou tendo que lidar com coisas tanto em baixíssimo quanto altíssimo nível;
A começar pela vida acadêmica, este trimestre a cadeira é de sistemas distribuídos, o contexto é:

  • comunicação com utilização de mensagens;
  • protocolos e semânticas;
  • tratamentos de erros, correções, tolerância a falhas;
  • tempo distribuído, ordens causais, exclusão mútua distribuída;

A linguagem de programação definida pelo professor (define:professor – Alguém que não é legal você contrariar) é JAVA. Sabe já fui xiita quanto a isto, mas para algumas coisas o Java realmente é uma mão na roda, por exemplo, faziam 4 anos desde a última vez que eu fiz um programa com janelinhas, e com Java consegui fazer um programa demo em menos de meia hora.

Outro ponto é: Objetos remotos. O Trabalho deste trimestre é fazer uma implementação utilizando Corba, e com Java isto é legal :) é muito simples compartilhar um objeto remoto utilizando Java, e eu sinceramente não sei porque este protocolo junto com o RMI (que é mais fácil ainda) não são utilizados em larga escala.

Saindo um pouco da vida acadêmica, caio na minha vida profissional, ai entramos em um outro extremo. Ai o contexto é outro:

  • kernel Linux, uCLibc, arm-linux-*
  • ARM, Atmel, TI
  • C e asm
  • NandFlash, Dataflash, EEPROM
  • 32MB, 4KB, 99Mhz…

E esta é a minha praia, eu sinceramente, sem brincadeira, fico feliz com os problemas que me aparecem lá, os últimos que me vem a cabeça…

  • fazer o suporte da INFERNO PACK para o u-boot mainline;
  • um patch com os drivers do INFERNO PACK para o kernel mainline e resolver os pepinos da integração deste com o PREMPT_RT;
  • resolver um problema da implementação de mutex na linuxthreads da uCLibc;
  • por o 2.6.33.5-rt + buildroot-2010.05 + um monte de aplicação em 3.5MB de dataflash;
  • provar para o pessoal do outro lado do barramento que a latência não é no Linux (eu adoro este);

Mas ultimamente um problema legal que tenho trabalhado é o fato do processador Atmel at91sam9g20 não conseguir ler a uma NAND Samsung de 512 mbit, faz mais de um mês que estou discutindo com a Atmel que o problema é a ROMBOOT do processador. O legal disto é que estou tendo bastante contato com o drivers/mtd/ e o código do bootstrap do processador.

Por fim, o lado hobbista… aaa, este é uma coisa só: kernel Linux/Tempo real. Pra quem não sabe, minha proposta de palestra para a LinuxCon foi aceita, em breve publicarei aqui o resumo dela e os slides. Mas bom, voltando ao assunto, ultimamente tenho lido bastante sobre tempo real, tanto teoricamente com o livro Real Time Systems quanto implementações no kernel Linux, como a implementação do HRT, DynTick, a proposta do escalonador EDF, alguns artigos sobre controle de admissão de processos de tempo real.

Enfim, como pode-se ver, meu tempo ultimamente tem passado desde registradores à objetos distribuídos… porém, pelo meu lado hobbista… tudo se resume na frase do Linus…

And yeah, I still think the hard-RT people are mostly crazy. — Linus;

O que ando fazendo…

Nestas duas últimas semanas tenho tido bons trabalhos, o primeiro foi uma experiencia com Flash NAND e sistemas de arquivos para Flash. Nesta brincadeira fiz um “BacaSoftware” para formatar, escrever, ler, comparar flash e arquivos escritos direto na flash… ta, eu já sei que o mtd-utils faz isto, mas sabe… foi tao divertido… poxa deixa-me ser criança e brincar um pouco.

Sobre os sistemas de arquivos utilizei o UBIFS, e após muitas lidas na FAQ e um Patch fiz ele funcionar… O que valeu a pena, obtive mais de 30% de compactação dos arquivos na FLASH, isto utilizando o modo de compactação mais “performático”. Além disto gracas ao sistema de cache do sistema de arquivos as velocidades de leitura e gravação são muito boas, espero em breve fazer um melhor artigo sobre isto.

Outra coisa legal é que o patch RT para o 2.6.31.6 e o RT1 do 2.6.38-rc8 estão congelado em um kit de desenvolvimento ARM que utilizo… Depurando pude ver que isto acontece depois do asm_do_IRQ da interrupção do console serial. Em uma conversa no #linux-rt@OFTC o tglx me deu a dica de ser o terminal compartilhando o IRQ com o rtc, batata, era isto mesmo, a saída 1 seria trocar o IRQ do console para um diferente do utilizado pelo rtc… porém a AIC (advanced Interrupt controller) do embarcado não suporta isto… Bom, como não é novidade: Gostei :) estou lendo todo o código de tratamento de IRQ do Linux, tanto normal quanto + rt… ainda a procura da solução…

Jprobe

  1. #include <linux/module.h>
  2. #include <linux/kprobes.h>
  3. #include <linux/fs.h>
  4.  
  5. static void jprobe_do_sys_open(int dfd, const char __user
  6. *filename, int flags, int mode)
  7. {
  8.         printk(KERN_INFO "filename: %s %d\n", filename, mode);
  9.         jprobe_return();
  10. }
  11.  
  12. static struct jprobe my_jprobe = {
  13.         .kp.symbol_name = "do_sys_open",
  14.         .entry = (kprobe_opcode_t *) jprobe_do_sys_open,
  15. };
  16.  
  17. int init_module(void)
  18. {
  19.         register_jprobe(&my_jprobe);
  20.         return 0;
  21. }
  22.  
  23. void cleanup_module(void)
  24. {
  25.   unregister_jprobe(&my_jprobe);
  26. }
  27.  
  28. MODULE_LICENSE("GPL");

ARM, debug, Monitor e Docbook

Esta foi uma ótima semana. Domingo a noite para começar bem, li sobre as versões dos processadores ARM e algumas tecnologias embarcadas nos processadores ARM, como Jazelle, NEON, mas acabei dando maior atenção ao artigo Improving ARM Code Density and Performance, que explica as instruções Thumb2, que possibilitam gerar código com maior densidade e com isto dar maior performance nos processadores por buscar menos informações fora do núcleo, felizmente esta semana consegui um kit de desenvolvimento com um processador Cortex-A8, que possui as instruções thumb2, vamos ver o que sai.

Durante a semana gastei bastante tempo estudando modos de depuração do kernel do Linux e comecei a escrever um artigo sobre depuração do kernel e aplicações no Linux, espero publica-lo em breve.

Sobre artigos, em meus novos desafios estou tendo a oportunidade de aprender várias tecnologias novas, e por que não escrever sobre elas? pensando nisto procurei sobre formatos de edição de livros e artigos, primeiro pensei no Latex, gostei do estilo de edição dele, muito simples, porém pareceu limitado, procurando mais, encontrei no DocBook tudo o que precisava, adicionei alguns links sobre as documentações que li sobre.

Este é o primeiro post no meu novo monitor de 19″, que está facilitando muito e minha vida, com ele é possível para deixar duas janelas visíveis ao mesmo tempo, espero não ficar vesgo…

Quarta feira entreguei a versão final do meu TCC I, o que foi um alívio…

E para não dizer que sou um nerd total, apanhei um monte no jiu jitsu… mas estou melhorando.

Esta é da semana passada mas, eu criei duas novas páginas no meu blog: links e src, nelas irei guardar links sobre coisas que ando lendo/estudado e alguns arquivos fontes, meus e de terceiros, que eu acho úteis e merecem ser compartilhados.

Analista de desenvolvimento: Linux C e redes

A tempos que venho me interessando pelo desenvolvimento de sistemas, principalmente embarcados, e isto me fez, no final do ano passado buscar um tema de TCC que pudesse ser um DEMO de como é esta área… dei sorte; consegui junto a equipe de pesquisa e desenvolvimento de software da empresa qual trabalho o tema: QoS em rede para central VoIP em Linux embarcado, pronto, era o que eu queria, Linux embarcado, C e redes, estou em casa.

No decorrer do primeiro semestre deste ano, grande parte do meu tempo livre, incluso finais de semana, foram dedicados a isto, e não é que peguei gosto pela coisa?

Ao mesmo tempo, via os grandes desafios da administração de sistemas ficarem cada vez menores… Com o tempo, tudo aquilo que era complexo e novo, tornou-se rotina… e o brilho foi diminuindo…

Certo dia, vi um discurso do Steve Jobs, onde ele falou algo como, “se hoje fosse seu ultimo dia, você gostaria de fazer o que está prestes a fazer hoje?”, e então, a cada manhã ao me perguntar, repetidamente, a resposta era: isto não me faz mais feliz… Queria algo novo. queria algo com desenvolvimento de Linux embarcado, C e redes…

Então decidi correr atrás, e felizmente, consegui uma transferência, após alguns namoros, na mesma empresa que trabalhava, para o desenvolvimento de centrais telefónicas, trabalhando com Linux embarcado, redes e C…

Esta foi a primeira semana na nova profissão, e todos os dias dessa semana, ao acordar, a resposta foi, sim, é aqui onde estavam meus ídolos, (Ken Thompson, Denis Ritchie), é aqui que quero estar… Linux embarcado, C e redes…

Bem-vindo Tuz

Sem muito tempo, como de praxe, vai um pequeno, mas memorável post.

Hoje foi lançado do kernel 2.6.29, e junto com as features, veio o Tuz:

Tuz

Tuz

O Tuz é um Diabo da tazmânia, desfarçado de pinguim… Bonitinho não? … ele será exibido no boot, no lugar  do Tux… mas ele é temporário… só para este Release… Seja bem-vindo :)

(get|set)sockopt

Menu de seleção de opções para fazer em uma sexta que você está de folga:
  1. 1: Ir a praia
  2. 2: Fazer uma trilha de bicicleta
  3. 3: Ver TV
  4. 4: Ler: "Programação para redes Unix"
  5. Digite sua Opção:
  6. 4
  7. Opção 4: você é um nerd.
  8.  
  9. - Eu   n ã o   s o u    N E R D…

Os sockets possuem algumas opções e ajustes que podem ser feitos, como por exemplo, o tamanho do buffer de envio e recebimento de pacotes, se o pacote pode ser enviado para broadcast (este somente para sockets de datagrama (ex: UDP)), o TTL do pacote, etc.

Um dos meios de ajustar estes valores é utilizando as chamadas do sistema getsockopt(2) e setsockopt(2)

int getsockopt(int s, int level, int optname, void *optval, socklen_t *optlen);
  1. int setsockopt(int s, int level, int optname, const void *optval, socklen_t optlen);

Os argumentos, são:

int s: Descritor do soquete aberto
int level: Nivel do protocolo que deseja alterar a opção (ip, tcp, udp…)
int optname: Opção que deseja alterar
void *optval: Um ponteiro para a variável ao qual o valor deve ser gravado em getsockopt() ou lido em setsockopt().
socklen_t optlen: Tamanho da variável optval

Os valores para level, optname e optval estão descritos nas sessões “Socket Options” de ip(7),tcp(7),udp(7),socket(7) e unix(7).

O código abaixo, trás dois exemplos de opções:

  • Aumentar o tamanho do buffer de recebimento
  • Liberar o envio de pacotes UDP para o endereço de broadcast da rede:

sockopt.c Continue reading ‘(get|set)sockopt’ »