ROCK STREET.

[fabim]

Pessoal.
Apenas para os que entende de Linux, e sabem sobre o que eu estou falando.

Eu possuo uma placa comercial que estamos utilizando em um equipo médico. Esta placa hoje esta rodando com o LPC1788 a 120mhz, e por ventura possui uma memoria externa no barramento de 16 bits MT48LC16M16A2, esta memoria esta rodando a 60mhz sem problemas.
Ela possui 4M* 16b * 4BNK = 32MB.

A alguns meses eu estou estudando sobre Linux, device drivers e afins, e cheguei a conclusão que agora possivelmente eu tenho o minimo necessário para iniciar algo real ao invés de ficar apenas lendo e simulando.

A placa tem disponível um soquete uC SD que esta ligado ao barramento dedicado.

Ou seja:
Eu tenho um display TFT, um SDcard, e uma memoria em 16 bits com 32MB.
Pelo que eu pude entender, o uClinux pode ser compilado em thumb etc.

Gostaria de saber quais os caminhos eu preciso ir para conseguir portar um uClinux para minha plataforma !!!?

Abraços

[xultz]

Cadê o verdadeiro fabim???
Um post inteiro escrevendo todas as palavras corretamente, sem xingar o Linux nenhuma vez, só pode ser um impostor!!! Alguém roubou o login e senha do fabim!!!

[chrdcv]

fabim, vc já tem o bootloader e kernel portado para a plataforma? Outra coisa, mencionou apenas a SDRAM. Onde irá gravar o bootloader? Pelo que ví no Reference Manual, o LPC1788 não possui bootloader interno (possui apenas um boot primário para escrita e leitura na flash interna).

[fabim]

fabim, vc já tem o bootloader e kernel portado para a plataforma?

Seu "homossexual pequeno", você não leu o que eu escrevi lá encima ?

Eu possuo uma placa comercial que estamos utilizando em um equipo médico. Esta placa hoje esta rodando com o LPC1788 a 120mhz, e por ventura possui uma memoria externa no barramento de 16 bits MT48LC16M16A2, esta memoria esta rodando a 60mhz sem problemas.
Ela possui 4M* 16b * 4BNK = 32MB.

A alguns meses eu estou estudando sobre Linux, device drivers e afins, e cheguei a conclusão que agora possivelmente eu tenho o minimo necessário para iniciar algo real ao invés de ficar apenas lendo e simulando.

A placa tem disponível um soquete uC SD que esta ligado ao barramento dedicado.

Ou seja:
Eu tenho um display TFT, um SDcard, e uma memoria em 16 bits com 32MB.
Pelo que eu pude entender, o uClinux pode ser compilado em thumb etc.

Gostaria de saber quais os caminhos eu preciso ir para conseguir portar um uClinux para minha plataforma !!!?

O Restante do texto abaixo, só pode ser lido por pessoas inteligentes.

A placa foi desenvolvida pelo Diego e Eu.
Passou com mérito no INPE sendo bombardeada por 10V-M, esta sendo manuseada sem gabinete por 1 anos, jogada para lá e para cá sem nenhum tipo de ressentimento. E estão todas funcionando perfeitamente.

Baseado no Hardware que eu possuo e desenvolvi, e baseando-me em um Kernel que o Miguel me forneceu, eu gostaria de saber por onde eu inicio meu caminho das "PREDA (para não decepcionar o xuxu)", para que eu possa fazer a roda rodar ?!

[chrdcv]

Então truta, o LPC1788 possui um boot primário para a Flash interna (Boot ROM), dessa forma o bootloader deverá ser gravado na Flash e então irá carregar a imagem do kernel externamente (no teu caso, muito provavelmente a partir do teu cartão) na SDRAM. O que foi passado pelo tcpip foi certamente o port completo do bootloader mais o kernel, então o primeiro passo é instalar a toolchain, compilar e gravar no teu uC o bootloader.

[fabim]

Ok.
Porém veja o seguinte.
Meu hardware esta com 16bits, eu tenho que compilar o kernel em thumb, e isto, se, ele suportar modo thumb para o LPC1788.
Veja que, não necessária mente a configuração do kernel que o miguel me arrumou, está a mesma da minha plataforma.
Eu preciso conferir isto, e como faço para conferir isto, e se estiver errado, como eu faço a correção ?

Compreendes ?

Link para o kernel está aqui: http://comunidadecristadeorlandia.com.br/arquivos/M3linux-2.6.zip

[chrdcv]

Hey Jow!

Após fazer o download verifiquei que trata-se do kernel. Novamente; deve ter o bootloader rodando primeiro na Flash.

Como compilar o uboot:
[url]http://www.lpcware.com/content/project/lpc177x8x-u-boot-port/u-boot-build-procedure
[/url]

Antes de compilar, dê uma checada nos códigos referente ao lpc1788, conterá muita informação sobre o ambiente, configuração de memória, etc...

Vc é rico, deve ter um JTAG, então por ele deverá gravar o *.hex gerado e MUITO provavelmente tb. deverá dispender algum tempo com as mensagens de erro que surgirão no terminal (sou otimista, considero que o u-boot irá ao menos reportar erros).

Como compilar kernel e busybox:
http://www.linux-arm.org/LinuxKernel/LinuxM3

Se me mandar uma placa montada, porto para vc de grátis!

[msamsoniuk]

urra fabim! o fato da memoria ter 16 bits de largura nao quer dizer que as instrucoes e operandos tenham que ter 16 bits. pior ainda, se o processador tiver um cache, o bus mais estreito sequer ira afetar a performance!

vc tem que se des-PIC-lizar: em 1979 o 68000 jah tinha core de 32 bits com bus de 8 ou 16 bits e, em 1982, o 68020 com core de 32 bits e cache on-chip funcionava em bus de 8, 16 ou 32 bits praticamente sem perda de performance!

http://ferretronix.com/tech/sbc/mc68000 ... nual_2.jpg

"break away from the past"!

Ok.
Porém veja o seguinte.
Meu hardware esta com 16bits, eu tenho que compilar o kernel em thumb, e isto, se, ele suportar modo thumb para o LPC1788.
Veja que, não necessária mente a configuração do kernel que o miguel me arrumou, está a mesma da minha plataforma.
Eu preciso conferir isto, e como faço para conferir isto, e se estiver errado, como eu faço a correção ?

Compreendes ?

Link para o kernel está aqui: http://comunidadecristadeorlandia.com.br/arquivos/M3linux-2.6.zip

[fabim]

sam, ai que esta o negócio onde quem começa a estudar sobre linumbed fica desanimado.

Veja, eu acredito que o kernel seja totalmente flexivel, a ponto de eu afirmar para ele que a memoria ram, que se inicia na posição X, e termina na posição Y, opera em largura fisica de 16 bits, e que o cache interno é de 68KB e opera com barramento de 32 bits.

Eu sinceramente acredito, que se eu compilar o kernel da forma que esta cruo, sem tomar os devidos procedimentos como prioridade, o sistema não vai funcionar.

O problema é, quais são as prioridades, como afirmar a forma operativa do sistema para o kernel, e o pior de tudo. Como bootar isto.

[barboza]

urra fabim! o fato da memoria ter 16 bits de largura nao quer dizer que as instrucoes e operandos tenham que ter 16 bits. pior ainda, se o processador tiver um cache, o bus mais estreito sequer ira afetar a performance!

Até porque tem instruções thumb com 32 bits de comprimento...

[RobL]

Sem em nada ajudar ao fabim, fiquei na dúvida. Se esqueceu de colocar o 2 após thumb, ignore o restante, mas penso que é isso :

Thumb, Thumb-2 e ARM (aqui nomes de sets de instrução).
Thumb - somente 16 bits
ARM - instruções somente com 32 bits.
Thumb-2 - superset com novas instruções, algumas com 32 bits.


CM3 usa Thumb/Thumb-2 (sem chaveamento mas com decodificador).

ARM7 (antigo) usa Thumb/ARM (com chaveamento 16bits ou 32bits)

Rapaz, estou cansado, no momento e aí a gente escreve até isso!!! Vou ver novela pra não encher o saco do forum. Ver novela é realmente o fim, não, isso não.

[msamsoniuk]

se tem mais de um thumb daih jah nao sei, a unica coisa que eu sei eh que no modo de operacao normal as instrucoes tem 32 bits de comprimento para gerar opcodes suficientes para acomodar operacoes condicionais do tipo condicao ? rx op ry -> rz : nop, onde x,y,z sao 0 a 15 e op eh uma operacao de 32 bits. em modo thumb as instrucoes tem 16 bits de comprimento para imitar o 68k/cf e trabalhar com operacoes imperativas do tipo rx op ry -> rx, onde x,y sao 0 a 7 e op tambem eh uma operacao de 32 bits:



soh que o arm tem o pior dos dois mundos: com 32 bits as instrucoes sao flexiveis e condicionais, mas consomem muito bandwidth e eh penoso em termos de performance, enquanto que com 16 bits eles sao compactas, mas nao sao flexiveis, pq com 16 bits nao dah para codificar todas as necessidades... as vezes tenho impressao que os caras que projetam os arms sao ex-funcionarios da microsoft, pq fazem umas coisas bem idiotas no comeco e depois ficam remendando!

aqui os opcodes normais:



aqui os opcodes em modo thumb:



o set de registros muda, mas continua de 32 bits. bom, muito primitivo isso tudo para mim! espero nunca ter q usar arm novamente na vida! :/

Sem em nada ajudar ao fabim, fiquei na dúvida. Se esqueceu de colocar o 2 após thumb, ignore o restante, mas penso que é isso :

Thumb, Thumb-2 e ARM (aqui nomes de sets de instrução).
Thumb - somente 16 bits
ARM - instruções somente com 32 bits.
Thumb-2 - superset com novas instruções, algumas com 32 bits.


CM3 usa Thumb/Thumb-2 (sem chaveamento mas com decodificador).

ARM7 (antigo) usa Thumb/ARM (com chaveamento 16bits ou 32bits)

Rapaz, estou cansado, no momento e aí a gente escreve até isso!!! Vou ver novela pra não encher o saco do forum. Ver novela é realmente o fim, não, isso não.

[mastk]

Eu que usei o 68K original...

Nao importa o tamanho do barramento, isso so tem impacto sobre a performace do sistema.

O 68K, tem instrucoes de 32 bits e seu barramento eh de 16 bits e tem ate versoes de 8bits e sem cache alguma, o processador tem a obrigacao de pegar os bytes que precisa e formar o byte, word, long ou que for por conta propria, sem que o usuario se preocupe com o tamanho do barramento, se o ARM, concerteza eh capaz disso, se nao for, eh uma piada de CPU.

[fabim]

Gente, fala de pic aqui não !!!
Ta parecendo que estão falando de pic, e poluindo o ambiente ARMesco.

No meu caso hoje em dia, eu estou tentando ficar acima da abstração, e não abaixo.
Eu só gostaria de saber se, existe a possibilidade de eu compilar o kernel para operar em modo thumb, pois meu barramento tem largura física de 16 bits, e esta operando a 60mhz.
Se sim, existe a possibilidade, eu acredito que eu tenho que avisar ele que ele vai rodar em 16 bits, e a largura da RAM que ele tem disponível.

Alguém pode me indicar algum lugar pra eu entender como funciona esta configuração ? e como faze-la-la.

[RobL]

Tem Thumb, nos antigos e Thumb2 nos CMx, além de Thumb.
Sim, na cabeça do micro todas instruções de 16bits são "convertidas" para 32 bits. Portanto só trabalha com instruções com 32bits.
Mas vamos tentar resolver o problema do fabim.