Cartão SD perdendo o boot depois de centenas de Liga/Desliga (Raspberry PI)

Sergio Soares

unread,

Oct 13, 2013, 6:57:38 PM10/13/13

to sis_emb...@googlegroups.com

Pessoal,

Estou desenvolvendo um produto utilizando Raspberry PI. Já estamos na fase final de desenvolvimento e decidimos fazer o seguinte teste: ligar e desligar o R-PI uma vez por minuto durante um dia inteiro para verificar se aconteceria algum problema e enfim aconteceu. Depois de muitos liga/desliga (não sei bem quantidade. ficou testando por horas, então estimo uns 300) o cartão de memória simplesmente "perdeu" o boot. Nem carregava mais nada na tela, ficou totalmente preta. Formatei o cartão e gravei novamente a minha distribuição Raspbian e voltou a funcionar. A questão é que não gostaria de vender um produto sabendo que vai dar problema em breve.

Meu software não faz muito uso do cartão de memória para gravação, apenas leitura na maioria das vezes.

Vocês tem alguma dica do que posso fazer para evitar esse tipo de problema? Comprar um cartão de memória melhor ajudaria? (aceito sugestão de boas marcas)

Um abraço e obrigado,

Sergio Soares.

Diego Sueiro

unread,

Oct 13, 2013, 7:19:14 PM10/13/13

to sis_emb...@googlegroups.com

Olá Sergio,

Provavelmente houve corrupção do sistemas de arquivos do cartão.

E infelizmente isso vai acontecer com qualquer cartão, mesmo aqueles com especificações industriais.

Acho que o Raspbian é baseado no Debian Wheezy e existe uma maneira de você configurar a distro para que ela faça correção automática do sistema de arquivos caso encontre falhas na hora do boot.

Para isso coloque a opção FSCKFIX=yes no arquivo /etc/defaukt/rcS.

Abraços,

--
*dS
Diego Sueiro

Administrador do Embarcados
www.embarcados.com.br

Engenheiro de Controle e Automação
UNIVERSIDADE FEDERAL DE ITAJUBÀ

/*long live rock 'n roll*/

--
Você está recebendo esta mensagem porque se inscreveu no grupo "sis_embarcados" dos Grupos do Google.
Para cancelar a inscrição neste grupo e parar de receber seus e-mails, envie um e-mail para sis_embarcado...@googlegroups.com.
Para postar neste grupo, envie um e-mail para sis_emb...@googlegroups.com.
Visite este grupo em http://groups.google.com/group/sis_embarcados.
Para obter mais opções, acesse https://groups.google.com/groups/opt_out.

Felipe de Andrade Neves Lavratti

unread,

Oct 13, 2013, 7:30:05 PM10/13/13

to sis_emb...@googlegroups.com

Não consegue alterar o sistema de boot para carregar uma imagem do cartão e montar o kernel em RAM junto com o filesystem, matava 2 coelhos com uma cajadada só, pois sistema de arquivos persistente em produto é foda.

2013/10/13 Diego Sueiro <diego....@gmail.com>

--

Skype: felipeanl

Sergio Soares

unread,

Oct 14, 2013, 3:56:18 PM10/14/13

to sis_emb...@googlegroups.com

Obrigado pela dica, Diego.

Felipe, não entendi muito bem o que sugeristes. Sou bem iniciante ainda no mundo do linux.

Parece que o problema na verdade foi ocasionado por um curto. Ontem à noite meu sócio me falou que ele provocou um curto acidentalmente e esqueceu de me avisar. Vou deixar testando novamente e se eu tiver algum problema posto por aqui.

Um abraço,

Sergio Soares.

Rodrigo 'Skhaz' Delduca

unread,

Oct 14, 2013, 5:15:45 PM10/14/13

to sis_emb...@googlegroups.com

Uma outra alternativa é o usar o SQUASHFS[1]

1 - http://squashfs.sourceforge.net/

2013/10/14 Sergio Soares <eng.serg...@gmail.com>:

http://www.nullonerror.org/
-- flipping bits whilst updating pixels

Flavio Castro Alves Filho

unread,

Oct 14, 2013, 5:36:23 PM10/14/13

to sis_emb...@googlegroups.com

Uma vez eu fiz um Linux funcionar na Ram através de um boot via squashfs.

Faz tempo ... rapaz .... 2010 ... com o Ubuntu Live CD.

Com a RaspPi eu não faço idéia de como fazer isso :-) ... Porém, é uma
solução bem interessante.

Abraço

Flavio

Em 14 de outubro de 2013 18:15, Rodrigo 'Skhaz' Delduca
<rodrigo...@gmail.com> escreveu:

Flavio de Castro Alves Filho

flavio...@gmail.com
www.linuxembarcado.com
Twitter: http://twitter.com/#!/fraviofii
LinkedIn profile: www.linkedin.com/in/flaviocastroalves

Cleiton Bueno

unread,

Oct 15, 2013, 11:32:38 AM10/15/13

to sis_emb...@googlegroups.com

No meu TCC esta implementado o kernel para subir e montar e meu filesystem a sacada foi squashfs como read-only. E utilizei um SD Card Class10 da Kingston suportado pelo RaspPI, na época tentei implementar MTD, e utilizaria um UBIFS para ter uma partição rw, mas estudando vi que quem abstrai esta etapa é o próprio chip do SD Card se não me engano é o FTL em nível kernel que interage desta maneira, então o chip implementar o "Wear Leveling" também conhecido como nivelamento de desgaste.

E até domingo ta rodando lá o uptime dele ta com 12 dias se não em engano e o timestamp do meu uControlador tinha visto deu quase 8 dias, mas eu tinha feito uma bateria de testes assim também em um final de semana mas era de 5 em 5 minutos eu abria/fecha um rele que desliga e ligava meu RaspPI e ele sobreviveu.

Atualmente ele esta:

kernel 3.6.11 compressão lzo
Filesystem rootfs squashfs com lzo e testei lzma tambem ambos como read-only
E uma partição como ext4 apenas para uns arquivos rrd (rrdtool).
O resto tudo como tmpfs.

SD Card: http://loja.planeteletronicos.com.br/ecommerce_site/produto_9796_9256_Cartao-Kingston-SDHC-Ultimate-X-100X-16Gb-Class-10

Acho que é este modelo.

Qualquer coisa da um toque que tentamos ajudar.

Rogerio Machado

unread,

Oct 18, 2013, 1:09:49 PM10/18/13

to sis_emb...@googlegroups.com

Isso soh vai funcionar se formatar o SD com um filesystem com Journal: ext3, ext4, xfs, ...

Tambem eh possivel criar 2 particoes na SD. Monta a particao 1 como FAT/ext2 read/only com os arquivos essenciais para o boot(fica imune a corrupcao do filesystem), E outra particao FAT ou outro filesystem com journal montada como R/W