ASM51

Pessoal,


Desculpa se a dúvida é elementar, mas eu já era inexperiente no Linux X86, e sou completamento novo no Linux p/ ARM.
Estou com um kit de desenvolvimento que possui as seguintes caracteristicas :

CPU---------1GHz ARM Cortex A8
DRAM---------1GB
STORAGE---------2GB NAND Flash, microSD card (TF) slot for up to 32GB

Atualmente podemos o configurar para realizar o boot ou pela NANDflash ou pelo SDcard.
Se for bootar pela NAND, por ter sobrado apenas ~450MB da instalação do Ubuntu, o programa que preciso instalar não caberá ( QTcreator ).
Porém, se for bootar pelo SDcard, dizem que não é recomendável, pois o processo de criação da imagem no cartão não avala bad blocks.

O que eu gostaria então, era de manter a configuração original de bootar pela NAND, mas instalar programas no cartão SD.
É possível isso ou estou falando besteira ?


+++

Sim é possível executar programas de onde você quiser, até mesmo da rede usando nfs ou outro sistema de arquivos.

Sobre badblocks de cartões SD eu uso SDCARD quem trata isso é o sistema de arquivos não o HW.

Você pode usar a formatação ext2/ext3/ext4 para formatar o SDCARD.

Eu não tenho certeza se a ferramente fsck.ext2 verifica os badblocks, mas tem esta ferramenta:

http://linux.die.net/man/8/badblocks ( Vou testar hoje )

Pior que badblocks na minha opinião:
Uma coisa pior que acontece com SDCARD e outros tipos de memória é o desgaste por muitas gravações.

A especificação do SDCARD diz que ele tem que ter algorítimo de "wear levening" para evitar desgastes rápidos do setor.

Existem alguns sites que dizem que não é bom usar sistemas de arquivo que possuem algorítimo de "wear levening" com SDCARDs pois este algorítimo interfere no algorítimo interno, mas eu tenho minhas dúvidas, pois ainda não tive tempo de testar. Alguns sistemas que tem este algorítimo são: JFFS2 ou UBIFS e deve ter outros.

Sobre o desgastes, já aconteceu comigo:
Fiz um projeto onde eu coletava informações e salvava no cartão um arquivo de textos. ( FAT16 ou FAT32 )
Quando o sistema estava conectado ao PC, o PC ficava lendo o arquivo e depois de lido mandava apagar.
O sistema registrava mais de 1000 arquivos por dia
o cartão num durava nem uma semana.

Neste projeto eu não tinha como colocar outro tipo de formato por falta de tempo e processamento, então eu fiz o seguinte:
Eu fico gerando entradas no arquivo de texto, e só apago quanto ele tiver mais de 4MB. Com isso eu num apago o cartão toda hora, eu percebi que o maior problema era no setor 0, pois quando você apaga/grava novo arquivo ele mexe na tabela FAT que é fixa no começo dos setores do sdcard.

Para mim, isso foi uma prova de que o algorítimo interno de nivelamento do sdcard não é eficiente, eu ainda não tive tempo de colocar um cartão com um sistema de FS com "wear leveling" e testar, mas ainda vou fazer isso e postar aqui os resultados.

Obs. depois que o cartão dava pau, num dava pra ler ele nem no PC, nem tentar formatá-lo, nem no linux.

Fica a dica, pois se você pretende usar o SDCARD para ficar gravando/lendo toda hora, provavelmente você terá problemas usando somente o cartão e sistemas de arquivos comuns sem nenhum outro tipo de técnica para evitar desgaste.

Olá Rodrigo,



Muito obrigado pelas dicas, e de fato há até pessoas que preferem essa ou aquela marca do cartão, que dizem ser mais confiável.
O que eu pretendia fazer era o seguinte :

Usar o SDcard somente durante o desenvolvimento, e no final, depois de tudo testado, fazer rodar na memória interna NAND.
Isso porque o arquivo executável gerado após a compilação seria relativamente pequeno, cabendo tranquilo nos ~450MB disponíveis.
( ao passo que a IDE descompactada, somada á outros aplicativos acesorios chegariam próximos dos 600MB )

Mas aqui vai outra pergunta, mas essa agora deve ser estúpida :
Seria possível não apenas executar programas no SDcard, mas instalar aplicativos, como IDEs via Synaptic, mesmo que o Ubuntu esteja rodando da NAND ?

A vantagem disso, seria poder usar um cartão SD maior para evitar a necessidade de uma compilação a partir de outra plataforma ( o cross-compiling que voce sugeriu anteriormente ) e mesmo se desse pau num SD, bastaria substituir por outro, já que o foco da execução final é na NAND.

Isso funciona ?


+++

Funciona, mas na minha opinião é mais produtivo ter as ferramentas de compilação em um PC potente.

Rodrigo_P_A escreveu:Funciona, mas na minha opinião é mais produtivo ter as ferramentas de compilação em um PC potente.

Poisé...mas não consegui avançar muito nisso...em cada lugar observo pessoas que apanharam feio pra conseguir fazer rodar, e muito mais experientes que eu nos toolchains da vida. Vou ter de conviver realmente com a menor potencia do core para compilar nele mesmo, mas pra quem veio do XT como eu, que tinha de tomar um café enquanto o PSCPICE simulava ou o BORLAND compilava, acredito que eu vá sobreviver ao QTcreator dentro desse core, que - convenhamos - não é tão fraco assim.

Mas o foco era realmente saber se é possível instalar o IDE remoto no SDcard, e obrigado pela confirmação; já dá pra planejar o trabalho desse modo.


+++

Dica: Veja se consegue instalar uma VM usando o VMWare, dê preferência ao DEBIAN 7 baixe o dvd dele.

Eu uso ele atualmente, é muito bom completo e estável.

Sobre as toolchains, veja da Menthor Graphics ( Code sourcery )
Veja também o linaro

Vai vendo isso em paralelo ao que você vai fazer na placa.

At+

Olha só o que eu achei:

http://stackoverflow.com/questions/4339 ... on-sd-card

Veja o que os caras falam sobre SDCARD e BadBlock

Rodrigo_P_A escreveu:...Veja se consegue instalar uma VM...

Rodrigo,


Não sei se estou raciocíninando corretamente, mas não tenho certeza se o ganho de produtividade compensaria o esforço empregado para fazer funcionar um toolchain que nunca trabalhei dentro de uma VM.

embora ainda não tenha de fato feito as instalações, o que pude pesquisar até o momento é que o Cortex-A8 não fica tão atrás assim do X68 para operações regulares de transferencia e cálculo sem FP : http://vanshardware.com/2010/08/mirror- ... ersus-x86/

Isso significa que para a aplicação final, que envolve processamento de imagem, com diversos cálculos, realmente o core é pouco potente, mas para as operações usadas na etapa de compilação, creio que a vantagem de rodar num X86 não seria tão drástica assim, será ?

Ou seja, em princípio a instalação do QT dentro da própria placa parece factível, ou não ?


+++

Ele ele num rodaria como meu PC com i7 3.4GHZ e 16GB ram.

Além disso dá pra manter uma repositório enorme de várias ferramentas no PC.

O tempo de escrita em um HD é menor do que em um SD.

Mas o melhor jeito é aquele que você gosta mais ou que lhe atender!

Se usando na placa te atende, vá em frente!

Olá André,

Na empresa onde eu trabalho, nossos produtos bootam via SD sem problemas (na verdade, via SDHC). Usamos um PowerPC para isso. E no produto antigo, usávamos MMCs sem problemas.

Eu desenvolvo apenas o HW, então não posso te dar muitas dicas sobre o sistema de arquivos. Mas se não me engano, o ext3 já é preparado para lidar com formatos de cartões SD.

Não sei se é a mesma situação que o Rodrigo_P_A colocou, mas o cartão dá muito problemas se vc não desligá-lo correntamente. Sempre, ao se desligar o sistema, vai ser necessário um halt ou shutdown, ou pelo menos um sync. Se ficar desligando o sistema sem esses procedimentos, o sistema se corrompe (e aí sim, corrompendo o sistema por algumas vezes, o cartão pode ser inutilizado).

De qualquer maneira, vai da aplicação também. Se sua aplicação requer operações de ligas/desliga constantes, SD realmente pode não ser a melhor solução. No nosso caso, usamos o SDHC em centrais telefônicas, que ficam ligadas constantemente.

Mas aqui vai outra pergunta, mas essa agora deve ser estúpida :
Seria possível não apenas executar programas no SDcard, mas instalar aplicativos, como IDEs via Synaptic, mesmo que o Ubuntu esteja rodando da NAND ?

A vantagem disso, seria poder usar um cartão SD maior para evitar a necessidade de uma compilação a partir de outra plataforma ( o cross-compiling que voce sugeriu anteriormente ) e mesmo se desse pau num SD, bastaria substituir por outro, já que o foco da execução final é na NAND.

Isso funciona ?

Funciona. Do ponto de vista do Linux, o cartão SD pode ser montado como um diretório qualquer, sem restrições de escrita/leitura. Seria só montar e usar.

ph , o Problema q eu relatei é de desgaste, não tem relação com desligamento indevido.

a ext3 é mais robusta contra desligamentos indevidos pois ele tem o algorítimo de "jornaling fs"

Olá Rodrigo,

Sim, você citou o desgaste.

Mas veja só, um cartão SD não é nada mais do que FLASHs NAND acessadas por um controlador SD. Logo, do ponto de vista do componente, não há diferença entre o desgaste de uma FLASH NAND normal e um cartão SD.

O que pode acontecer é de ter muitas SDs de pouca qualidade. Isso pode ser contornado comprando SDs de um fabricante mais qualificado, que permite mais escritas e que seja mais rápido que o normal.

pbernardi escreveu:Olá Rodrigo,

Sim, você citou o desgaste.

Mas veja só, um cartão SD não é nada mais do que FLASHs NAND acessadas por um controlador SD. Logo, do ponto de vista do componente, não há diferença entre o desgaste de uma FLASH NAND normal e um cartão SD.

O que pode acontecer é de ter muitas SDs de pouca qualidade. Isso pode ser contornado comprando SDs de um fabricante mais qualificado, que permite mais escritas e que seja mais rápido que o normal.

Não é esse o problema, já testei com vários fabricantes. Mas já resolvi da forma que citei.

A questão é que o "wear leveling" que a especificação diz que tem não funciona bem, você pode ver que muitas pessoas tem este problema com android quando gravam muitas vezes o cartão.

Eu queria ajudar o André e acabei desfocando o assunto principal.

Depois eu abro um novo tópico com esta discussão para continuarmos!

Eu mesmo quero fazer vários ensaios e postar os resultados.

Pessoal,



Gostaria de agradecer, pois vocês ajudaram bastante.
Eu já havia esquecido que conforme o Unix, provavelmente o Linux também mapeie externamente os dispositivos de armazenamento de modo transparente.

O fato é que agora vai dar pra fazer o boot e instalar na SD ao menos durante a etapa de desenvolvimento.


+++