Tamanho de ram para uClinux LPC1788 120mhz.

[chrdcv]

NXP Cortex M3 @120MHz ~ 32 BogoMIPS
Motorola ColdFire V2 ~ 98 BogoMIPS

Putz, sem noção mesmo esses uP's...

chrdcv

[tcpipchip]

exatamente! rodava bem rapido!

http://framework.sourceforge.net/pics/c ... linux.html

Marcelo
Voce deve ter visto o UCLINUX rodando num COLDFIRE da NETBURNER, o MOD5270 ?
O que achou, rápido hein ?

Pois é...eu apresentei ele em 2009 para uma empresa aqui da regiao e eles ficaram de cara com performence, tanto com o RTOS como UCLINUX...acabaram adotando UCLINUX...e hoje...utilizam os NETBURNER..

COLDFIRE é F.

[fabim]

Para quem quiser mais detalhes.

http://www.linux-arm.org/LinuxKernel/LinuxM3

Tudo que eu estou fazendo, é baseado nisso ai.

Pelo que eu estudei.
Vou ter 3 boots.
1° - Vai fazer a configuração inicial dos registradores, pll etc
2° - Vai fazer a configuração calibração e tudo mais da emc.
3° - vivi ou das-uboot, que ira abrir o kernel, e chamar o mesmo

Apartir dai, o kernel se vira pra abrir o fs, carregar o que for necessário no rC etc.
O primeiro e segundo boot, sem problemas.
O uboot ta sendo um problema chato bagarai.
Tipo, como trabalhar com ele, para que ele possa puxar tudo de uma flash ou um uSD ? etc
Eu estive imaginando ele como se fosse um programa C normal, mais não achei nada parecido com um main.. hehe

[fabim]

Para quem quiser mais detalhes.

http://www.linux-arm.org/LinuxKernel/LinuxM3

Tudo que eu estou fazendo, é baseado nisso ai.

Pelo que eu estudei.
Vou ter 3 boots.
1° - Vai fazer a configuração inicial dos registradores, pll etc
2° - Vai fazer a configuração calibração e tudo mais da emc.
3° - vivi ou das-uboot, que ira abrir o kernel, e chamar o mesmo

Apartir dai, o kernel se vira pra abrir o fs, carregar o que for necessário no rC etc.
O primeiro e segundo boot, sem problemas.
O uboot ta sendo um problema chato bagarai.
Tipo, como trabalhar com ele, para que ele possa puxar tudo de uma flash ou um uSD ? etc
Eu estive imaginando ele como se fosse um programa C normal, mais não achei nada parecido com um main.. hehe

[msamsoniuk]

como diriam as adolescentes lesbicas q dividiram minha vodka hoje a noite: porraaaaaan meunnnnnnnn!!! eh soh o *uboot e o uclinux*. se tem uboot para a plataforma alvo, o proprio uboot faz *tudo*. se nao tem, eh pq a plataforma alvo na presta... mude de plataforma! bom, nao ando fazendo isso todo dia pq nao precisa qdo tudo funciona, mas normalmente eh simples: baixa o uboot, uclinux e o toolchain , este ultimo para poder compilar, obvio...o uboot deveria ter *tudo* q vc precisa para bootar *sem* precisar meter a mao na massa, exceto dizer onde esta a flash e ram. no uclinux tem q dar uns pitacos, tipo, quero awk, quero bash, etc...mas nada baixo nivel. uboot instalado, tudo eh *variavel de ambiente*: se vai bootar do mmc, se vai puxar uma imagem e fazer uma ramdisk, se vai bootar via tftp/nfs, etc. ateh o endereco p/ onde copia a imagem do kernel na ram eh variavel de ambiente. pensando do ponto de vista de HW: uboot faz tudo q precisa p/ conseguir puxar o kernel de algum lugar... soh nao serve p/ mais coisa pq nao escalona processo! mas serve p/ puxar o kernel. com o kernel na mao, vc puxa o rootfs de qq lugar, escalona processos e faz qq coisa. entao eh soh uboot e uclinux... se precisar complicar, eh pq a plataforma nao eh suportada! quem ve soh HW quer q o SW faca milagres... e eh o que acontece 99% das vezes!

Para quem quiser mais detalhes.

http://www.linux-arm.org/LinuxKernel/LinuxM3

Tudo que eu estou fazendo, é baseado nisso ai.

Pelo que eu estudei.
Vou ter 3 boots.
1° - Vai fazer a configuração inicial dos registradores, pll etc
2° - Vai fazer a configuração calibração e tudo mais da emc.
3° - vivi ou das-uboot, que ira abrir o kernel, e chamar o mesmo

Apartir dai, o kernel se vira pra abrir o fs, carregar o que for necessário no rC etc.
O primeiro e segundo boot, sem problemas.
O uboot ta sendo um problema chato bagarai.
Tipo, como trabalhar com ele, para que ele possa puxar tudo de uma flash ou um uSD ? etc
Eu estive imaginando ele como se fosse um programa C normal, mais não achei nada parecido com um main.. hehe

[fabim]

Tchelo.
No alto daquele cume, havia uma roseira...

Cara, sobre alvo eu estou a alguns meses pesquisando...
Veja só.

Eu cheguei a dois modelos.
LPC1788-NXP
I.MX237-FSCL

Ai fui jogando na balança.
LPC = jtag-uLink, keil, facil fazer coisas na unha, facil colocar o uClinux, facil comprar, barato , muiiiita documentação disponivel, consumo baixo, processamento razoavel.

I.MX = Jtag dedicado e caro, IDE não generica de mercado, dificil fazer coisas na unha, tem mmu pode rodar linux puro, facil comprar, preço razoavel, pouuuuuca documentação disponivel, consumo alto, processamento alto.

Estes são os pontos que me fazem escolher um uC, como pode ver o LPC ganhou. Porém eu estou desenvolvendo a plataforma para os dois... E vou ter disponivel os dois...

Uma coisa que esta me chapando o coco.
Eu vi uma plataforma com o LPC2478, com display TFT em 16 bits, porém rodando com SDRAM de apenas 16 bits e o uClinux.
Será que o uClinux roda em thumb ? ou esses caras que possuem EMC consegue usar uma memoria externa de 16bits como 32 ?

[tcpipchip]

Parte da tua duvida esta aqui
http://www.uclinux.org/pub/uClinux/archive/0393.html

[msamsoniuk]

Uma coisa que esta me chapando o coco.
Eu vi uma plataforma com o LPC2478, com display TFT em 16 bits, porém rodando com SDRAM de apenas 16 bits e o uClinux.
Será que o uClinux roda em thumb ? ou esses caras que possuem EMC consegue usar uma memoria externa de 16bits como 32 ?

o core e o barramento sao desacoplados em qq microprocessador "moderno"... e quando eu falo "moderno", estou falando em 8086 e 68000. no 8086 e 8088 vc podia rodar exatamente o mesmo software de 16 bits, sendo que no primeiro vc usava memorias de 16 bits e no segundo memorias de 8 bits. a performance era menor em funcao do gargalo de barramento, mas sem impacto algum no software. no 68000 era bem pior, pq o core eh 32 bits: no 68008 o barramento era de 8 bits, no 68000 o barramento era de 16 bits e no 68020 o barramento podia ser configurado dinamicamente para ter 8, 16 e 32 bits todos no mesmo sistema. em nenhum caso havia qq impacto no software, que sempre trabalhava internamente com 32 bits, exceto o impacto na performance, em funcao do barramento mais largo ou mais estreito. o fato das instrucoes do 68000 terem 16 bits de largura nao significa que ele nao possa rodar em barramentos de 8 bits. de fato, as instrucoes podem ter 16, 32 ou 48 bits de comprimento, o que derruba em parte as vantagens de um barramento de 16 bits. mas como as memorias SDRAM e DDR mais populares sao de 16 bits, eh logico escolher essa largura para obter um custo melhor. a desvantagem de ter um barramento mais estreito, normalmente, eh compensado pelas caches no core.

[fabim]

Esta ai uma coisa que me chapa o coco 2.
Eu acredito que quando fazemos uma adaptação do kernel para um target é necessário que informemos dados como:

Comprimento da ram que terá disponivel.
Endereço de onde inicia a ram.
Se a ram é 16 ou 32 bits.

Porque eu imagino assim. Quando você vai no fabricante e baixa um kernel para uma plataforma de exemplo onde existe N Bytes de ram etc.

Eu tive algo estranho outro dia. Eu tenho uma plataforma de aprendizado com o 2440, ele tem 64MB ram, eu fui tentar usar um kernel que eu achei para uma plataforma que tinha 128MB. Estava dando uns erros no startup e nada subia. Ai parei e fui interpretar os erros, e um deles era exatamente que o kernel foi configurado para 128MB, e com 64 estava havendo erro ciclico etc.

[chrdcv]

Então truta, em relação ao LPC1788, se não tem port no uboot ou redboot ainda, vamos arregaçar as mangas e fazer. Acho que seria uma boa idéia partir do que foi feito para o LPC2468/78

Essa empresa: http://www.emcraft.com, portou o uclinux para o LPC1788, porém ainda não ví nada de código fonte na seção de downloads.

Se interessar, podemos fazer um "bem bolado", caso tenha alguma placa para testes (pretendo fazer meus testes utilizando somente o qemu).

chrdcv

[msamsoniuk]

opa opa opa! nao confunda as coisas!

quando o uboot inicia, ele obviamente precisa configurar os chip-selects para as memorias, portanto ele precisa ter em algum lugar as informacoes sobre a geometria da flash (largura do bus, tantos setores, setores de tal tamanho) e da sdram (largura do bus, tamanho das paginas, quantidade de bancos, temporizacao, etc).

vc usar uma memoria de 16 ou 32 bits significa que o uboot vai programar na inicializacao, por exemplo:

#ifdef BUS_WIDTH_32
DDRCTRL0->BUS_WIDTH = 1;
#else
DDRCTRL0->BUS_WIDTH = 0;
#endif

mas o resto do codigo nao precisa se importar com isso.

quer dizer, normalmente NAO tem pelo meio do codigo coisas como:

#ifdef BUS_WIDTH_32
unsigned long i;
#else
unsigned short i;
#endif

pq eh indiferente! o core suporta um unsigned long independente da largura do bus, fazendo uma (bus de 32 bits) ou duas (bus de 16 bits) transferencias sem que o usuario perceba a diferenca, exceto eh claro pela performance.

daih pensa soh: eh funcao do uboot puxar o kernel da flash, rede ou mmc , colocar na ram e mandar rodar. entao a memoria jah esta configurada! a unica coisa que o kernel precisa conhecer, de verdade, eh o tamanho total, o que na realidade poderia ser feito empiricamente, tentando escrever na memoria ateh achar a borda.

porem isso nao eh verdadeiro em processadores com barramento assincrono, como por exemplo os 68k e coldfires: se vc escrever fora da area dos chipselects, o processador pendura ou forca um bus error, se houver watchdog de barramento! na medida que o primeiro target do uclinux na decada de 90 foi o 68k, eu diria que eh um habito quase legado deles ter que informar os pontos de inicio e fim da memorial, ao inves de tentar descobrir empiricamente.

mas em placas com powerpc o que eu vejo eh um pouco diferente: normalmente se usam pentes de memoria DDR e estes, por sua vez, possuem pequenas EEPROMs seriais que informam a geometria das memorias, temporizacao e tamanho. daih o negocio fica automatico!

Esta ai uma coisa que me chapa o coco 2.
Eu acredito que quando fazemos uma adaptação do kernel para um target é necessário que informemos dados como:

Comprimento da ram que terá disponivel.
Endereço de onde inicia a ram.
Se a ram é 16 ou 32 bits.

Porque eu imagino assim. Quando você vai no fabricante e baixa um kernel para uma plataforma de exemplo onde existe N Bytes de ram etc.

Eu tive algo estranho outro dia. Eu tenho uma plataforma de aprendizado com o 2440, ele tem 64MB ram, eu fui tentar usar um kernel que eu achei para uma plataforma que tinha 128MB. Estava dando uns erros no startup e nada subia. Ai parei e fui interpretar os erros, e um deles era exatamente que o kernel foi configurado para 128MB, e com 64 estava havendo erro ciclico etc.

[fabim]

Intão samsonite.
Ai são coisas chapantes.

Tipo, estes defines etc.

Em quais arquivos eles ficam, etc. Vão ânus até conseguir aprender tudo..

[fabim]

Bom.
Acabei o esquema, montei todos os phoot´s, conferi ligações.
Agora perdeu a graça, pois.

Não achei o fonte do uClinux para o lpc1788 em lugar algum.

Ai eu tava aqui agora mexendo, e achei um arm9 with mmu da nxp bem barato, roda a uns 250 mega.

Que 6s acham, fazer com CM3 ou com ARM9 ?

[chrdcv]

Então trufa, ops truta, deu uma olhada no link que indiquei? Outra coisa, vc não tem um projeto (refiro-me ao hardware) rodando no LPC24X ? Então talvez fosse melhor usar o LPC1788 (não sei se são pino-a-pino compatíveis) e fazer um teste inicial para ver se "roda" o que é necessário, daê então vê se realmente é necessário mudar para um outro dispositivo. Disse que o outro tem MMU e roda a 250MHz e é mais barato. Chegou a comparar o restante de periféricos bem como se a tecnologia de memórias utilizadas são as mesmas?

chrdcv

[fabim]

haram .
Comparei.
Sim, cum 2478 funciona sim.
Co 1788 não achei o uClinux aberto.
Mabhostrask.
Sim 1788 1.15Dmips - MHZ, é pTp compativel com o 2478 de 0.80Dmips-MHZ.
Alpiste ?