RAM ARM. putz

[fabim]

OBS>:
OS LPC´s.
TEM a RAM de dados, e de programa.
A RAM de programa, é como se fosse uma continuação da flash, ou seja o interpretador olha esta ram, como se fosse uma flash.
A ram de dados, é ram de dados ora raios.

Eu tinha confundido a bagaça..

[tcpipchip]

O exemplo abaixo é o que uso para carregar a imagem do UCLINUX do cartao MMC para uma memória ESTÁTICA.
Veja o MAM para programar os ciclos de leitura e escrita...



/*#######################################################################################
ARM Linux MMC Boot Loader

Copyright (C) 2004 Ulrich Radig

Bei Fragen und Verbesserungen wendet euch per EMail an
Dieses Programm ist freie Software. Sie können es unter den Bedingungen der
GNU General Public License, wie von der Free Software Foundation veröffentlicht,
weitergeben und/oder modifizieren, entweder gemäß Version 2 der Lizenz oder
(nach Ihrer Option) jeder späteren Version.

Die Veröffentlichung dieses Programms erfolgt in der Hoffnung,
daß es Ihnen von Nutzen sein wird, aber OHNE IRGENDEINE GARANTIE,
sogar ohne die implizite Garantie der MARKTREIFE oder der VERWENDBARKEIT
FÜR EINEN BESTIMMTEN ZWECK. Details finden Sie in der GNU General Public License.

Sie sollten eine Kopie der GNU General Public License zusammen mit diesem
Programm erhalten haben.
Falls nicht, schreiben Sie an die Free Software Foundation,
Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307, USA.
#######################################################################################*/

#include "main.h"

/*#######################################################################################
Config System
#######################################################################################*/
void SystemInit(void)
{

// --- enable and connect the PLL (Phase Locked Loop) ---
// a. set multiplier and divider
SCB_PLLCFG = MSEL | (1<<PSEL1) | (0<<PSEL0);
// b. enable PLL
SCB_PLLCON = (1<<PLLE);
// c. feed sequence
SCB_PLLFEED = PLL_FEED1;
SCB_PLLFEED = PLL_FEED2;
// d. wait for PLL lock (PLOCK bit is set if locked)
while (!(SCB_PLLSTAT & (1<<PLOCK)));
// e. connect (and enable) PLL
SCB_PLLCON = (1<<PLLE) | (1<<PLLC);
// f. feed sequence
SCB_PLLFEED = PLL_FEED1;
SCB_PLLFEED = PLL_FEED2;

// --- setup and enable the MAM (Memory Accelerator Module) ---
// a. start change by turning of the MAM (redundant)
MAM_MAMCR = 0;
// b. set MAM-Fetch cycle to 3 cclk as recommended for >40MHz
MAM_MAMTIM = MAM_FETCH;
// c. enable MAM
MAM_MAMCR = MAM_MODE;

// --- set VPB speed ---
SCB_VPBDIV = VPBDIV_VAL;

// --- map INT-vector ---
SCB_MEMMAP = MEMMAP_USER_FLASH_MODE;
}

void swiirqp (void)
{
printf("\nint\n");
}

/*#######################################################################################
Main Programm
#######################################################################################*/
int main(void)
{

signed char stat;

void (*kernelstart)(void);

SystemInit();

uart0Init(B9600, UART_8N1, UART_FIFO_OFF); // setup the UART

PCB_PINSEL2 = 0x0F814924; //Init Extendet Memory

printf("\n\n\r");
printf("*******************************************\n\r");
printf("* *\n\r");
printf("* ARM Linux MMC Boot Loader *\n\r");
printf("* *\n\r");
printf("* Copyright (C) 2005 by Ulrich Radig *\n\r");
printf("* *\n\r");
printf("*******************************************\n\n\r");

while (mmc_init() != 0) //setup the MMC Card
{
printf("**MMC/SD - Card not found! **\r");
}

//Speichern der Cluster Size und Cluster Offset (Anfang Datenbereich)
Cluster_Data_Store();
//Initialisierung der MMC/SD-Karte ENDE!

load_file (FILE1,(int*)KERNEL_START);
load_file (FILE2,(int*)BOOTIMG_ADDR);

printf("\n\n\rLinux wird gestartet!\n\n\r");

PCB_PINSEL0 = 0x00000005;
PCB_PINSEL2 = 0x0F814924;
BCFG0 = 0x2000AEEF;
BCFG1 = 0x2000FBFF;
BCFG2 = 0x1000FFEF;
BCFG3 = 0x0000FFEF;
VICDefVectAddr = 0x81000018;

kernelstart = (void (*)(void))KERNEL_START;//KERNEL_START;
(*kernelstart)();

printf("Never reached this!!");

while(1)
{
}
return(0);
}

[msamsoniuk]

entao nao pode usar cada byte da flash/ram do arm com uma funcao diferente de dados e codigo? que lixinho de processador hein...

OBS>:
OS LPC´s.
TEM a RAM de dados, e de programa.
A RAM de programa, é como se fosse uma continuação da flash, ou seja o interpretador olha esta ram, como se fosse uma flash.
A ram de dados, é ram de dados ora raios.

Eu tinha confundido a bagaça..

[proex]

entao nao pode usar cada byte da flash/ram do arm com uma funcao diferente de dados e codigo? que lixinho de processador hein...

OBS>:
OS LPC´s.
TEM a RAM de dados, e de programa.
A RAM de programa, é como se fosse uma continuação da flash, ou seja o interpretador olha esta ram, como se fosse uma flash.
A ram de dados, é ram de dados ora raios.

Eu tinha confundido a bagaça..

Sim, é um lixo, Eu tambem estou decepcionado com ARM, vou voltar para o PIC 16F84, é muito melhor. Quem sabe até eu aprenda a mexer com o 68000 de 64 pinos DIP, isso sim é processador.

[vtrx]

Calma proex,o 68000 é um processador,não um µc e suas intruções são superiores.
PS:Antes que eu cometa uma 'gafe',não lí o set de instruções de um ARM...hehe

[proex]

Eu tô calminho, só estou tirando um pelinho do Marcelo

[fabim]

Podem parar com a putexaria, só eu aceito ser introduzido com o 68000.

eim ?

[mastk]

Eu tenho alguns aqui fabim, vai te machucar, 64Pin com 900 mils de espacamentos entre as fileiras

E pow, esse cache eh estranho hein? Se vc ta pegando da ram, teoricamente ele deveria ser mais simples, o processador ignora ele, afinal fica 1 para 1 o pipeline ne?

[fabim]

Eu tenho alguns aqui fabim, vai te machucar, 64Pin com 900 mils de espacamentos entre as fileiras

E pow, esse cache eh estranho hein? Se vc ta pegando da ram, teoricamente ele deveria ser mais simples, o processador ignora ele, afinal fica 1 para 1 o pipeline ne?

olha, sinceramente pelo datasheet, eu acho que

[polesapart]

entao nao pode usar cada byte da flash/ram do arm com uma funcao diferente de dados e codigo? que lixinho de processador hein...

Lá vem o marcelo. Tira esse 68xxx do traseiro!

É claro que pode. O ARM tem endereçamento linear. O tal Memory acceleration module que tem na LPC é uma espécie de micro-cache que fica entre a flash e o barramento (portanto é transparente, vc não endereça ela a parte). Na verdade ele consiste de alguns buffers: a flash tem uma largura grande (128 bits se não me engano), todo fetch da flash é armazenado numa s-ram minúscula da MAM, existem buffers separados pra fetch de dados/instruções e um buffer pra branches, pra diminuir o impacto do fetch em loops quando estes não cabem em 128 bits (ou seja, a maioria deles ). Estes buffers são maiores que um fetch, mas não lembro o tamanho. O desempenho de execução linear desta solução acaba sendo 0 wait states, os saltos "a esmo" acabam pagando o preço de um fetch da flash, mas como a flash é fisicamente incapaz de dar 0 wait-states por ex. se o clock da cpu é de 72mhz, o custo ainda assim é zero pq os branches teriam este mesmo tempo em wait states ... Um outro detalhe desta solução é que cada fetch da flash consome um x de energia, tendo um buffer permite economizar um pouco de energia, especialmente em loops apertados. A MAM pode ser usada apenas pra economizar energia, programando ela pra emular os wait-states originais da flash, caso o código base precise de temporização deterministica (sempre usei os periféricos pra fazer este tipo de coisa, nunca precisei contar tempo de instruções em loops hehe).


Isto tou falando dos arm7, eu não estudei o esquema dos cortex-m3 da nxp, suponho que sejam um pouco diferentes pq estes tem barramentos separados pra dados e codigo (mas tbm tem endereçamento linear), eu suponho que eles tenham implementado um buffer de porta dupla pro MAM ou mesmo MAMs separadas.

Mas as áreas de sram do chip mapeadas como RAM podem ser usadas pra dados e/ou código sem problema, exceto numa determinada versão de um determinado chip que tinha uma errata: a sram "dedicada" pra ethernet não podia ser usada pra executar código, apenas dados, o que não é lá grande problema.

[fabim]

ta, buffer linear.
Confundi tudo agora, que raios quer dizer isto ?

[polesapart]

Não sei, eu não disse buffer linear, eu usei a expressão linear em dois pontos (posso ter usado em três, mas isto não vem ao caso) :

Endereçamento linear -> Todas as instruções de acesso a memória enxergam todo o espaço de endereçamento (0 - 2^32), ou seja, sem bancos, páginas, e mais importante ainda, sem ter dois espaços de endereçamento separados (com instruções específicas pra ler de um e de outro, como o AVR [se não confundi o AVR com alguma outra tralha que já vi]).

Execução linear -> Quando uma instrução é executada após a outra, ou seja, todas menos os saltos e exceto quando ocorre uma exceção (interrupção ou de outro tipo qualquer).


Dependendo do user manual que vc pegar da nxp, o funcionamento da MAM está razoavelmente bem explicado. Mas nos datasheets não fala nada de útil...

[fabim]

OPS<>: endereçamento linear, continuo sem paginação.
Eu me confundi, sorry.

á sim, aí tudo bem, datashit.
concordo, mais os UM são bem menos malas de se entender.
axo que foi o xultz que disse que o branch é de 2^30, pois endereçamento é palavra de 4 bytes.
Bom não vem ao caso, agora eu tendeu!! thankyou.

[msamsoniuk]

pois eh, o 680x0 tem um core CISC com arquitetura de harvard que mistura dados e instrucoes na cache... enquanto o ARM7 tem um core RISC com arquitetura de von-neumann que separa a cache de dados da de instrucoes... eh algo no minimo ironico!

[polesapart]

O endereçamento da CPU é de 32 bits mesmo, 2^32, com granularidade byte a byte.

O fetcher/prefetcher de instruções do núcleo da CPU é que mascara os 2 bits menos significativos (já que as instruções são alinhadas a cada 32 bits), mas no modo thumb apenas o bit menos significativo é mascarado, neste caso o fetch de instruções abrange um espaço de 2^31.

Como em tese a CPU nunca vai pedir uma instrução desalinhada, talvez o fetcher sequer tenha a linha de endereços do bit menos significativa, mas no caso do ARM7, como só tem um barramento, certamente ela está ligada ao núcleo pra poder alimentar o pipeline com dados. É claro que ela normalmente só é usada quando se usa um ldrb/srtb ou coisa que o valha, pois as outras instruções de load/store exigem o alinhamento a 32 ou 16 bits conforme o tamanho de dado.

Bom, fora isto existe o ldr de 32 bits em endereços desalinhados, mas como isto não produz o resultado esperado (eu nunca entendi direito o que acontece, parece que o core lê um dado do endereço alinhado, mascarando os bits menos significativos e rotaciona ele pelo número expresso pelos bits menos significativos, ou algo tão doido quanto isto).

Aliás, isto é uma dica legal: códigos como o abaixo que funcionam bem no intel x86 ou em µCs de 8 bits costumam compilar normalmente no arm mas o resultado não é o esperado:

Código: Selecionar todos


// Imagine que ptr aponta pra 4 bytes que vc recebeu via serial e armazenou num buffer por ex.
//  do tipo static char buffer[4];
// O código abaixo possivelmente falhe em arquiteteturas que exigem alinhamento em 32 bits ou mais,
//  pois o buffer pode ter sido alocado em área desalinhada.
unsigned int read_int_32(const char *ptr)
{
   return *(unsigned int *)ptr;
}

// Um exemplo pior ainda seria:
unsigned int read_int_32(const char *ptr)
{
   return *(unsigned int *)ptr + 1;
}