ROCK STREET.

[chipselect]

veja se tem alguma coisa que você consegue aproveitar.

http://ecos.sourceware.org/tools/linux-thumb-elf.html

[msamsoniuk]

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.

podia comecar explicarndo para o fabim que o que ele esta querendo nao tem nexo!

eh soh olhar o set de instrucoes em modo thumb: falta tudo, pq nao dah para condensar um set de instrucoes viavel em uma instrucao de apenas 16 bits. o resultado eh que o compilador vai precisar aumentar o numero de instrucoes para suprir a diferenca, mas daih a vantagem do codigo menor e com menos bandwidth desaparece.

de fato, o codigo fica mais compacto, digamos, em 75% do tamanho. mas a performance cai na mesma proporcao. e francamente, usar um processador de 60MHz e ter apenas 75% da performance p/ economizar alguns bytes nao eh interessante (com 32MB de memoria, ele tem bastante memoria e nao tem pq ficar economizando!).

isso sem falar que a ideia do fabim de que em thumb vai ficar adequado a largura do bus nao tem nexo: o kernel trabalha quase que em tempo integral com variaveis de 32 bits e todos os acessos de dados vao continuar fazendo duas transferencias na memoria.

sem falar que usar 32 bits em um bus de 16 bits eh um ganho comprovado pelos varios computadores com 680x0 ao longo da historia!

[fabim]

veja se tem alguma coisa que você consegue aproveitar.

http://ecos.sourceware.org/tools/linux-thumb-elf.html

Nada!!

[mastk]

Me corrija, se eu estiver errado Fabim, mas o que deseja, nao se trata apenas de recompilar o binario que tem em maos no Modo Thumb?
E tal como o Sam e RobL falaram, o que economiza de barramento, se perde na hora de execultar.

[msamsoniuk]

a unica coisa que vc vai avisar para ele eh que a memoria externa tem determinada geometria: 16 bits de largura, organizacao tanto por tanto e tantos bancos.

querer otimizar p/ a largura do barramento nao foi feito 10 anos atras qdo o primeiro uclinux p/ 68328 saiu e nao eh agora que vai ser feito! primeiro que o kernel alinha tudo em fronteiras de 32 bits e sempre usa 32 bits, pq mesmo em um bus de 16 ou 8 bits vai ser mais eficiente do que reescrever o kernel e todas as aplicacoes do universo p/ otimizar variaveis p/ 8 ou 16 bits. segundo que as caches on-chip escondem e otimizam o fluxo de dados entre o barramento interno e o barramento externo.

entao, independente de usar thumb ou normal, o kernel sempre vai trabalhar com inteiros de 32 bits. agora, sobre a largura das instrucoes, o thumb vai te dar uma condensacao de codigo, porem ele tem uma falha gravissima: nao tem opcodes suficientes em 16 bits p/ expressar codigo equivalente aos opcodes de 32 bits. eh um fato, pq nem no 68000 ou coldfire (a referencia que diz q opcodes de 16 bits sao melhores) isso eh verdade: eles usam opcodes de 16, 32 e 48 bits!

o resultado eh que compilar o kernel no modo thumb impacta a performance: vc precisa as vezes de 2 instrucoes thumb p/ fazer o que seria feito com uma instrucao normal. e isso afeta o tamanho, entao no lugar de 50%, na verdade vc tem uns 75% em tamanho. e isso tb afeta a performance, pq se antes vc fazia uma operacao em 1 clock, agora vc pode precisar de 1 ou 2 clocks. o resultado eh uns 75% da performance... e daih parece que o conserto sai mais caro: vc queria otimizar o fluxo de instrucoes em funcao do bus e o resultado acaba sendo justamente o contrario!

a solucao, se vc quer insistir na ideia, eh o thumb-2, que funciona parecido com o 68k/cf, com instrucoes de tamanho variavel. mas tambem nao eh a solucao melhor... a melhor solucao em performance continua sendo usar 32 bits.

dah uma ollhada aqui:

http://elinux.org/images/8/8a/Experimen ... -2_ISA.pdf

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.

[fabim]

Sam, eu não quero insistir em nada, acho que não soube me expressar.

Start hitory
Diego e eu, fizemos uma IHM, com ARM7tdmi LPC2478, com memoria externa para o TFT com 16 bits.
Esta IHM foi certificada no INPE, bombardeada de todas as formas possíveis com ruídos, tanto induzidos quanto conduzidos.
As interfaces analógicas foram colocadas a prova de todas as formas possíveis.
Em poucas palavras é uma obra de arte, foi a concepção da minha experiência!!!

Ai eu vi na NET um kit rodando com 16bits e uClinux, e um outro com 32bits.
Vi muito pouca diferença entre os dois!!!

lembra, "it works ? Then live this !!!"

A plataforma já existe, foi certificada, e tudo mais. Eu não quero mexer no layout, trocar pinos e tudo mais. Até como aprendizado eu gostaria de portar o uClinux para minha plataforma, para que eu possa aprender.

[tcpipchip]

Voce esta com os source da OLIMEX ?

[fabim]

Detalhe.:
LPC2478 foi então upgradezado para um Pin to Pin compatible LPC1788. E eu portei tudo do ARM7 para o Cortex M3 LPC1788.

Miguel, não possuo os fontes da Olimex. Eles só fornecem o fonte mediante contrato para compradores.

Bom trocando tudo que foi falado agora por miúdos.
Eu possuo o kit ARM9 da friendly arm. Poderia muito bem mexer nele, porém, eu tenho muito pouco tempo pra mexer neste kit, e muito tempo mexendo na IHM. Por este motivo, eu quero utilizar este kit como aprendizado.

Abraços

[mastk]

Fez algum teste de performace entre uma versao de outra?

[msamsoniuk]

talvez vc esteja procurando no lugar errado, veja esse post:

http://www.embeddedrelated.com/groups/A ... w/3941.php

o que tem todo o nexo: o kernel eh puxado p/ a sdram pelo uboot e, se o kernel tentar reconfigurar a sdram, o conteudo eh perdido e o kernel crasha. entao vc tem que procurar essa configuracao no uboot.

daih no uboot tem um diretorio chamado board, que contem varias descricoes de placa. em particular, tem uma lpc2292sodimm q eu imagino ser parecida com sua plataforma (na real, vc vai usar uma parecida como base e criar a sua, com seus dados especificos!). tem uns codigos em particulares, mas nao sei realmente se vc precisa de algo diferenciado. em include/configs tem umas configuracoes mais especificas e tem um lpc2292sodimm.h, que contem algumas coisas interessantes, por exemplo:

/*-----------------------------------------------------------------------
* Physical Memory Map
*/
#define CONFIG_NR_DRAM_BANKS 1 /* we have 1 bank of DRAM */
#define PHYS_SDRAM_1 0x81000000 /* SDRAM Bank #1 */
#define PHYS_SDRAM_1_SIZE 0x00800000 /* 8 MB SDRAM */

#define PHYS_FLASH_1 0x80000000 /* Flash Bank #1 */
#define PHYS_FLASH_SIZE 0x00200000 /* 2 MB */

#define CFG_FLASH_BASE PHYS_FLASH_1

/*-----------------------------------------------------------------------
* FLASH and environment organization
*/
#define CFG_MAX_FLASH_BANKS 2 /* max number of memory banks */
#define CFG_MAX_FLASH_SECT 1024 /* max number of sectors on one chip */

/* timeout values are in ticks */
#define CFG_FLASH_ERASE_TOUT (2*CFG_HZ) /* Timeout for Flash Erase */
#define CFG_FLASH_WRITE_TOUT (2*CFG_HZ) /* Timeout for Flash Write */

#define CONFIG_ENV_IS_IN_FLASH 1
#define CONFIG_ENV_ADDR (0x0 + 0x3C000) /* Addr of Environment Sector */
#define CONFIG_ENV_SIZE 0x2000 /* Total Size of Environment Sector */

em particular, essa droga de placa nao tem configuracao de largura do bus... mas acho que o caminho eh por ae, ou seja, compilar em thumb *nao* vai fazer reconfiguracao do bus para 16 bits como vc esta querendo.

Sam, eu não quero insistir em nada, acho que não soube me expressar.

Start hitory
Diego e eu, fizemos uma IHM, com ARM7tdmi LPC2478, com memoria externa para o TFT com 16 bits.
Esta IHM foi certificada no INPE, bombardeada de todas as formas possíveis com ruídos, tanto induzidos quanto conduzidos.
As interfaces analógicas foram colocadas a prova de todas as formas possíveis.
Em poucas palavras é uma obra de arte, foi a concepção da minha experiência!!!

Ai eu vi na NET um kit rodando com 16bits e uClinux, e um outro com 32bits.
Vi muito pouca diferença entre os dois!!!

lembra, "it works ? Then live this !!!"

A plataforma já existe, foi certificada, e tudo mais. Eu não quero mexer no layout, trocar pinos e tudo mais. Até como aprendizado eu gostaria de portar o uClinux para minha plataforma, para que eu possa aprender.

[tcpipchip]

talvez vc esteja procurando no lugar errado, veja esse post:

http://www.embeddedrelated.com/groups/A ... w/3941.php

o que tem todo o nexo: o kernel eh puxado p/ a sdram pelo uboot e, se o kernel tentar reconfigurar a sdram, o conteudo eh perdido e o kernel crasha. entao vc tem que procurar essa configuracao no uboot.

daih no uboot tem um diretorio chamado board, que contem varias descricoes de placa. em particular, tem uma lpc2292sodimm q eu imagino ser parecida com sua plataforma (na real, vc vai usar uma parecida como base e criar a sua, com seus dados especificos!). tem uns codigos em particulares, mas nao sei realmente se vc precisa de algo diferenciado. em include/configs tem umas configuracoes mais especificas e tem um lpc2292sodimm.h, que contem algumas coisas interessantes, por exemplo:

/*-----------------------------------------------------------------------
* Physical Memory Map
*/
#define CONFIG_NR_DRAM_BANKS 1 /* we have 1 bank of DRAM */
#define PHYS_SDRAM_1 0x81000000 /* SDRAM Bank #1 */
#define PHYS_SDRAM_1_SIZE 0x00800000 /* 8 MB SDRAM */

#define PHYS_FLASH_1 0x80000000 /* Flash Bank #1 */
#define PHYS_FLASH_SIZE 0x00200000 /* 2 MB */

#define CFG_FLASH_BASE PHYS_FLASH_1

/*-----------------------------------------------------------------------
* FLASH and environment organization
*/
#define CFG_MAX_FLASH_BANKS 2 /* max number of memory banks */
#define CFG_MAX_FLASH_SECT 1024 /* max number of sectors on one chip */

/* timeout values are in ticks */
#define CFG_FLASH_ERASE_TOUT (2*CFG_HZ) /* Timeout for Flash Erase */
#define CFG_FLASH_WRITE_TOUT (2*CFG_HZ) /* Timeout for Flash Write */

#define CONFIG_ENV_IS_IN_FLASH 1
#define CONFIG_ENV_ADDR (0x0 + 0x3C000) /* Addr of Environment Sector */
#define CONFIG_ENV_SIZE 0x2000 /* Total Size of Environment Sector */

em particular, essa droga de placa nao tem configuracao de largura do bus... mas acho que o caminho eh por ae, ou seja, compilar em thumb *nao* vai fazer reconfiguracao do bus para 16 bits como vc esta querendo.

Sam, eu não quero insistir em nada, acho que não soube me expressar.

Start hitory
Diego e eu, fizemos uma IHM, com ARM7tdmi LPC2478, com memoria externa para o TFT com 16 bits.
Esta IHM foi certificada no INPE, bombardeada de todas as formas possíveis com ruídos, tanto induzidos quanto conduzidos.
As interfaces analógicas foram colocadas a prova de todas as formas possíveis.
Em poucas palavras é uma obra de arte, foi a concepção da minha experiência!!!

Ai eu vi na NET um kit rodando com 16bits e uClinux, e um outro com 32bits.
Vi muito pouca diferença entre os dois!!!

lembra, "it works ? Then live this !!!"

A plataforma já existe, foi certificada, e tudo mais. Eu não quero mexer no layout, trocar pinos e tudo mais. Até como aprendizado eu gostaria de portar o uClinux para minha plataforma, para que eu possa aprender.

[tcpipchip]

"TCPIPCHIP, não possuo os fontes da Olimex. Eles só fornecem o fonte mediante contrato para compradores. "

Contrato ? Para usar o UCLINUX ?

[fabim]

"TCPIPCHIP, não possuo os fontes da Olimex. Eles só fornecem o fonte mediante contrato para compradores. "

Contrato ? Para usar o UCLINUX ?

Sim para utilizar a distro deles...
O diego tem um kit da olimex com o 2478, o cd acompanha apenas os bins nada de fontes...
Entramos em contato na época, solicitamos fontes etc, e eles deixaram claro jogada de grana etc.

[fabim]

Fez algum teste de performace entre uma versao de outra?

Sim fiz sim uma comparação.
Veja, eu tenho uma RIT de 1ms, ali dentro eu leio o touch através de um chip dedicado calculando float e polinômio de segunda ordem, faço a lógica do encoder ou spin knob, e mais uma pá de coisas.

Para fazer tudo isto em média o arm demorava coisa de uns 600uS, retirando o SPI e me baseando apenas nos cálculos eu observei uma melhora de performance baseado no tempo de.
ARM7 rodando a 72mhz = 280uS médio.
CM3 rodando a 120mhz = 100uS médio.

Escrever os fontes no display então, ficou coisa de criança...

Cara a velocidade pra movimentar dados, fazer cálculos, ficou infinitamente melhor. sem comparações mano !!!

[chrdcv]

fabim, acabei de cross-compilar o u-boot para o LPC1788:

Código: Selecionar todos

chr@chr-desktop:~/tmp/fabinux/u-boot$ make
...
...
...
/home/chr/tmp/fabinux/arm-2011.09/bin/arm-none-eabi-objcopy -O srec u-boot u-boot.srec
/home/chr/tmp/fabinux/arm-2011.09/bin/arm-none-eabi-objcopy --gap-fill=0xff -O binary u-boot u-boot.bin
lpc17_fcg u-boot.bin u-boot-lpc.bin
File u-boot.bin loaded with size 126184 bytes
Word 0: 0x1000ff90
Word 1: 0x00000161
Word 2: 0x00000135
Word 3: 0x00000139
Word 4: 0x0000013d
Word 5: 0x00000141
Word 6: 0x00000145
Word 7: 0xeffef8de (cksum total: 0x00000000)
File u-boot-lpc.bin created with size 126184 bytes
/home/chr/tmp/fabinux/arm-2011.09/bin/arm-none-eabi-objcopy --gap-fill=0xff -O ihex u-boot-lpc.bin u-boot-lpc.hex -I binary
/home/chr/tmp/fabinux/arm-2011.09/bin/arm-none-eabi-objdump -d u-boot > u-boot.dis
chr@chr-desktop:~/tmp/fabinux/u-boot$

Tive que fazer uma pequena e insignificante alteração no make para que ele pudesse achar o caminho do aplicativo a parte que gerar o CRC da "imagem" (neste caso o ".bin gerado): lpc17_fcg

Como faço para te passar o *.hex (caso interesse em fazer um teste inicial?)

chrdcv