Month: May 2010

Diario de bordo: Linux Embarcado na China

Hoje esta’ completando duas semanas que estou em Beijing.China trabalhando na inicializacao do hardware de nosso novo disposito. A placa deste novo dispositivo esta muito mais estavel que a do modelo anterior, sinal de que desta vez eles fizeram um trabalho melhor.

A inicializacao da memoria foi tranquila, utilizei um JTAG Abatron BDI3000 e consegui inicializar o processador e a memoria sem nenhum problema. O passo seguinte foi inicializar o bootloader (U-Boot) direto da memoria RAM, em principio imaginei que nao teria nenhum problema, pois eu ja havia feito isso varias vezes antes na placa de avaliacao da Freescale (FSL p/ intimos). Mas nao e’ que isto comeca a garrar! Perco quase um dia tentando fazer isso funcionar e nada, eu nao precisava de manual, afinal eu estava seguro que estava fazendo tudo certo, como disse antes, quando voce faz uma coisa varias vezes voce sempre tem certeza que esta certo.

Entao lembrei que eu havia documentado o procedimento no site http://www.imxdev.org, na duvida nao custa nada conferir ne? E eis que descubro a falha trivial, eu confundi o endereco de carga da memoria, estava colocando 0x98000000 e era 0x97800000. Caramba que vacilo, tambem quem manda confiar na memoria, estou ficando velho, rs.

O proximo desafio seria ainda mais cruel, com o bootloader inicializado estava na hora de ativar o suporte a NAND Flash no U-Boot e, com ele inicializado pela RAM, gravar sua copia direto na flash. E mais uma vez Edsel Murphy estava certo, ativando a NAND Flash a inicializacao do U-Boot para no momento de deteccao dela. Depois de um dia inteiro debugando, resolvi contactar meus amigos na FSL Brasil e saber “o que ta pegando”. Teoricamente ninguem sabe e ninguem viu nada desse tipo, mas reza a lenda que se voce for bootar pela NAND voce deveria colocar resistores de pull-up nos em todos os pinos NANDF_RBx (Ready/Busy). Isto e’ um BUG no controlador de NAND, documentado na Errata ENGcm11004.

Como no meu caso nao estou bootando pela NAND, estou carregando o U-Boot para RAM via JTAG e partindo de la’ entao este problema nao deve me afetar. O cara que projetou a placa tambem contactou o suporte da FSL China e mais uma vez eles sao enfaticos: o problema so existe para quem esta bootando da NAND. E la se vai mais um dia. Entao meu amigo da FSL Brasil confirma o problema: mesmo se nao tiver bootando da NAND precisa de colocar os resistores de pull-up. E nao e’ que colocando os resistores a NAND “funciona” (continue lendo para saber o por que das aspas).

Entao com o U-Boot inicializado e a NAND detectada esta na hora de gravar a copia do U-Boot na NAND e mudar o switches para inicializar pela NAND. Tenho duas opcoes para fazer a copia pra a memoria RAM: usar o comando “loady” do U-Boot e fazer a transferia via serial ou usar o proprio JTAG para fazer a copia. Fiz via JTAG, e’ bem mais rapido que via serial. Entao la esta’ o U-Boot gravado na NAND, hora de mudar os switches e … oops, cade o bootloader iniciando pela NAND? Nao pode ser… Confiro novamente todos os switches e tudo certo.

Entao resolvi conferir o conteudo gravado na NAND e ver se estava igual ao que eu havia gravado e infelizmente nao estava. O conteudo parecia seguir uma certa logica com o conteudo original, mas definitivamente eram diferente. Vamos ver, a Errata dizia que os dados poderiam ser corrompidos caso o modo usando fosse RBB_MODE = 1 e ADD_OP = 1. Simples, e’ so eu mudar o modo para RBB_MODE = 0 e pronto.

Nada feito, a lei de Murphy e’ realmente implacavel, descubro a Errata ENGcm09970 que diz que o controlador NAND nao funciona corretamente quando no modo RBB_MODE = 0. “Ah para, ohh”, desse jeito eu vou voltar pra roca pra plantar batatas. Bom, so me resta uma opcao: ADD_OP = 0.

“E’ TETRA!!!, E’ TETRA!!!, O BRASIL E’ TETRA!!!”

Finalmente funcionou!!!

Consigo bootar a placa pela NAND, agora os demais problemas vou deixar para comentar outro dia, com certeza eles nao sao nada perto deste problema da NAND.

Voltando a China, quer dizer, ao tema inicial do post. Nao e’ facil definir este pais, as pessoas, a cultura, etc.
Parece que voce realmente esta em outro planeta. Aqui o traco mais marcante e’ a mistura do velho (milenar) com o novo, da riqueza e prosperidade com a pobreza e sujeira. E’ comum ver nos fundos de construcoes modernas e luxuosas, casas simples que resistem em continuar la’, talvez rejeitando quantias altissimas por elas.

Enfim, todo mundo que vem pra China sempre reclama da comida, mas e’ estranho, nao tive nenhum problema com isso. Ontem mesmo experimentei o tradicionalissimo ovo podre. O gosto e’ muito bom, voce so’ nao deve ficar pensando no que esta comendo e apreciar o paladar. Na minha infacia minha mae morava e trabalha em outra cidade, entao tinhamos que comer a “gororoba” que meu pai fazia. Acho que por isso nao sinto tanta difenca assim 🙂

Este post ja ficou enorme, entao vou finalizando, ainda tenho muito trabalho pela frente.

Removing Windows password from Linux

You can remove your Windows password from your Linux system, just install this software:

sudo apt-get install chntpw

Then mount your windows partition and go to this directory:

cd /mnt/windows/Windows/System32/config

To list users on Windows system execute:

chntpw –l SAM

To remove/change a password just type the chntpw command followed by -u “user name” and SAM:

chntpw –u Administrator SAM

Source: http://www.howtogeek.com/howto/windows-vista/change-your-forgotten-windows-password-with-the-linux-system-rescue-cd/

Economizando nas ligacoes da China para o Brasil

Assim que cheguei aqui na China eu adquiri um SIM Card da China Mobile e descobri que existe uma forma mais barata de fazer ligacoes para telefones fixos no Brasil.

Basta digitar 12593 antes do numero desejado. A ligacao passa a custar 2 RMB por minuto (algo em torno de R$ 0,67). Exemplo: 1259300XXYYYYYYYY, onde XX e’ o DDD do estado e YYYYYYYY e’ o numero do telefone desejado.

Infelizmente esta dica nao funciona para ligar para telefones celulares no Brasil.

Google nao desenvolveu nem 1/5 das modificacoes do kernel do Linux para adicionar support ao Android

Muito tem sido discutido sobre o fato do Google nao contribuir de volta com as modificacoes feitas no kernel do Linux, mas poucas pessoas sabem que o Google nao desenvolveu nem 1/5 (isso mesmo, nem 20%) da linhas de código necessarias para fazer o Android funcionar sobre o kernel do Linux.

– Como eu descobri isso?

É muito simples, basta voce olhar neste patch que Ben Leslie (da OK Labs) limpou e usou para adicionar suporte ao Neo1973 no Android:

http://benno.id.au/android/android-noqemu-nogoldfish-noyaffs2.diff

Neste patch podemos ver que mais de 80% das linhas de codigo sao referentes ao Binder e que foram desenvolvidas pela Palmsource.

O mais engracado nesta historia e’ que a ACCESS (antiga Palmsource) e’ concorrente do Android e nem mesmo participa da OHA (Open Hand Alliance), mas sim da OMA (Open Mobile Alliance).