MMC Treiber Optimierung mittels CPM

Sklaventreiber
Günther
Developer
Beiträge: 587
Registriert: Freitag 9. September 2005, 21:48

Re: Serial Communication Controler SCC2

Beitrag von Günther »

just_me hat geschrieben:Hoppla, soeben habe ich mit Freude gesehen, dass die Pinbelegung bei dem mmc2.c Treiber für den im PowerPC vorhandenen Serial Communication Controler SCC2 passt :D :D
Hi just_me,

hast du an der Sache weitergeforscht? Finde ich sehr spannend. Ich habe in der Arbeit mal vor Jahren vom 823 den SPI, SMC und den Interuptcontroller programmiert und wollte mich da mal wieder aufschlauen;). Das mit den SCC und den Strobes ist mir aber im Manual irgendwie etwas kurz erklärt (16.7.4.5) :gruebel: . Für die Sache würde ja dann L1TXDA, L1RXDA, L1ST3 und L1ST4 verwendet. Aber was wäre davon der clock (den müßte der core ja selber generieren???)

Über die Microcodes habe ich in der Kürze nicht viel gefunden. Im Manual steht ja auch nur das diese von Freescale für zukünftige Protokolle geliefert werden. Gibt es irgendwo eine Beschreibung wie diese Microcodes aussehen? Ev. kann ich mal bei mir intern oder bei Freescale nachfragen, ob es entsprechende Microcodes gibt (vielleicht sogar einen zum emulieren einen zusätzlichen SPI kanals)

Günther
Houdini
Developer
Beiträge: 2183
Registriert: Mittwoch 10. Dezember 2003, 07:59

Beitrag von Houdini »

Für die Sache würde ja dann L1TXDA, L1RXDA, L1ST3 und L1ST4 verwendet. Aber was wäre davon der clock (den müßte der core ja selber generieren???)
L1RCLKA/L1TCLKA (befeuert mit einen BRG?)
just_me
Einsteiger
Einsteiger
Beiträge: 123
Registriert: Montag 28. November 2005, 11:31

Re: Serial Communication Controler SCC2

Beitrag von just_me »

Günther hat geschrieben:hast du an der Sache weitergeforscht?
Leider bin ich dabei nicht weit gekommen. - Schluss war bei einer Firma, die die Microcodeprogrammierung kommerziell anbot (den Link habe ich nicht mehr zur Hand) und wohl ein Interesse daran hatte, die Programmierung als nahezu unmöglich darzustellen:)
Günther
Developer
Beiträge: 587
Registriert: Freitag 9. September 2005, 21:48

Beitrag von Günther »

Wie sieht es denn mit den Optimierungsbemühungen aus? Die SPI C-Emulation würde sich ja noch beschleunigen lassen.

Gibt es bezüglich CPM-Unterstützung schon was ? Wie oben geschrieben, fehlt mir da ein wenig der SCC-Überblick. Es scheint ja mit dem SCC-Strobes möglich zu sein, ganze Datenbuffer rauszuclocken, aber im Moment keine Ahnung wie das hinhauen soll. Bei der Sagem scheinen mir dazu die richtigen PINs am Modem-Connector zu fehlen. Bei der Nokia habe ich noch nicht geschaut (werde mir ev. auch die entsprechenden Ports bei der Sagem vom Board holen)

Gibt es denn irgend eine Übersicht, welche PINs am Nokia-Port noch frei verfügbar sind (inkl IDE)?

Gibt es den noch allgemeine Probleme mit dem Treiber ? (bekomme erst nächste Woche den bestellten SD-Kartenleser, dann werde ich mal in die Praxis gehen ;)
Günther
Developer
Beiträge: 587
Registriert: Freitag 9. September 2005, 21:48

Beitrag von Günther »

TaGana hat geschrieben:Theroretisch könnte man die SD karte noch im SD modus betreiben (4 bit datenbreite), die zwei zusätzlich benötigte I/O Leitungen sind auch noch da, das würde den durchsatz noch weiter beschleunigen und die CPU entlasten, wenn doch das protokoll verfügbar währe ... ist leider NDA.
Wenn ich das richtig verstehe, darf der SD Bus Mode (1-bit oder 4-bit) in OpenSource Projekten nicht eingesetzt werden, richtig? Das Protokol läßt sich nämlich durchaus über google auffinden.
just_me
Einsteiger
Einsteiger
Beiträge: 123
Registriert: Montag 28. November 2005, 11:31

Beitrag von just_me »

Günther hat geschrieben:Wenn ich das richtig verstehe, darf der SD Bus Mode (1-bit oder 4-bit) in OpenSource Projekten nicht eingesetzt werden, richtig? Das Protokol läßt sich nämlich durchaus über google auffinden.
Ich finde den SD Bus Mode im 4-bit Modus nicht so attraktiv wie es zunächst scheinen mag:

Der 4-bit SD Modus würde im "bit-banged" Mode ja vermutlich nicht reichen, um Videodaten wegzustecken oder zu liefern.
Und wenn der Transfer über den SCC2 abgewickelt würde, könnte schon der 1-bit Modus (egal ob als MMC oder SD) gerade so reichen?

Da es (ausser der Festplatte:) wohl keine Datenquelle/-senke mit größerer Transferrate als der der Ethernet Schnittstelle gibt, müsste man nicht höher springen als 1-bit MMC über SCC2?

Oder würdest Du den "4-bit bit banged SD-Modus" als Erweiterung für den Flashspeicher nutzen wollen?
Günther
Developer
Beiträge: 587
Registriert: Freitag 9. September 2005, 21:48

Beitrag von Günther »

just_me hat geschrieben:[
Da es (ausser der Festplatte:) wohl keine Datenquelle/-senke mit größerer Transferrate als der der Ethernet Schnittstelle gibt, müsste man nicht höher springen als 1-bit MMC über SCC2?
Wenn das mit dem SCC klappt sehe ich das genauso. Hast Du den schon eine Idee wie man den SCC für den mmc2 initialisiert?
just_me
Einsteiger
Einsteiger
Beiträge: 123
Registriert: Montag 28. November 2005, 11:31

Beitrag von just_me »

Günther hat geschrieben:Hast Du den schon eine Idee wie man den SCC für den mmc2 initialisiert?
Nein - ich konnte nirgends Dokumentation oder Microcode Sources für den SCC finden. Any ideas where to get that?
Günther
Developer
Beiträge: 587
Registriert: Freitag 9. September 2005, 21:48

Beitrag von Günther »

just_me hat geschrieben:
Günther hat geschrieben:Hast Du den schon eine Idee wie man den SCC für den mmc2 initialisiert?
Nein - ich konnte nirgends Dokumentation oder Microcode Sources für den SCC finden. Any ideas where to get that?
Mhh, ich dachte das man da auch ohne zusätzliche microcodes weiterkommen könnte, (nein?). zB. in 16.7.4.5 wird über strobes gesprochen welche daten bitweise rausclocken (ist mir aber noch nicht klar wie das für unsere Zwecke funktionieren könnte und vielleicht geht es ja auch nicht..)
just_me
Einsteiger
Einsteiger
Beiträge: 123
Registriert: Montag 28. November 2005, 11:31

Beitrag von just_me »

Günther hat geschrieben:Mhh, ich dachte das man da auch ohne zusätzliche microcodes weiterkommen könnte, (nein?).
Leider werde ich aus 16.7.4.5 nicht schlau - es scheint mir eher ein Modus für ein spezifisches Protokoll zu sein (figure 16.50 macht nach jeweils 4 bit eine Pause).

Es scheint allerdings noch ein:
MPC823I2CMC I2C/SPI Microcode Package for MPC823 and MPC821 (02/06/97)
zu geben, an das man allerdings nur mit gültigem Account bei Freescale heranzukommen scheint. Obs passt weiss ich nicht...
Günther
Developer
Beiträge: 587
Registriert: Freitag 9. September 2005, 21:48

Beitrag von Günther »

just_me hat geschrieben:Es scheint allerdings noch ein:
MPC823I2CMC I2C/SPI Microcode Package for MPC823 and MPC821 (02/06/97)
zu geben, an das man allerdings nur mit gültigem Account bei Freescale heranzukommen scheint. Obs passt weiss ich nicht...
Da hatte ich auch schon geschaut, ist aber leider nicht das was wir brauchen:

MPC8XX I2C/SPI MICROCODE PACKAGE SPECIFICATIONS
The modified I2C/SPI programming model allows concurrent operation of Ethernet and I2C or
SPI by solving the parameter ram conflict caused by the fact that some of the Ethernet parameters
overlay the I2C/SPI parameters. This is done by mapping the I2C/SPI parameters to other
dual ported RAM area (relocatable parameter ram).


Da gibt es übrigens auch einen Microcode Assembler, aber ohne Doku ist das natürlich zwecklos. (Mir wurde von meinen Kollegen auch bestätigt, das die Microcodes eher etwas mühsam sind, gerade weil es dazu kaum Doku gibt..., Allerdings, eine SPI-Microcode wäre wahrscheinlich noch die einfachste Aufgabe)

Folgendes habe ich mir noch angeschaut :

Der SCC2 im Transparent und NMSI Mode wäre schick gewesen (das Syncbyte wäre dann das start block byte 0xFE und die 512 Datenbytes würden dann vollautomatisch in den Buffer geladen, incl CRC16 Berechnung bei Bedarf) , aber leider haben wir die entsprechenden PINS nicht zu Verfügung (TXD1/RXD1 ):cry: .

Also beim SMC2 nachgeschaut (wegen SMTXD2,SMRXD2), aber der kann im NMSI und Transparent Mode nicht auf ein Sync-Byte warten (nur externes Sync-Signal) :evil:

Bleibt also nur noch den TDM mit dem SCC2/SMC2 zu kombinieren, da müßte man eigenlich die Port frei wählen können. Bin ich aber gerade noch dran mir das durchzulesen (16.7 ff). (Um ehrlich zu sein lese ich das Kapitel schon zum 3-4 mal durch, und erst langsam verstehe ich was die meinen ;) ). Da müßte sich doch ein paar freie Pins konfigurieren lassen, oder?

Wenn das klappen würde wäre es super, weil dann vor allem die Kommunikation mit der SD-Karte bezüglich der Frequnz (20Mhz, oder sind es doch 25MHz?) definierter wäre.

Leider ist das alles recht kompliziert und zeitaufwendig :cry: (macht aber Spaß ;)

Hier mal nur meine aktuelle Liste der Modem-GPIOs
Sagem:
PA8 L1RXDA, SMTXD2 (MMC2_DI)
PA9 L1TXDA, SMRXD2 (MMC2_DO)
PB16 L1ST4, L1RQA (MMC2_CS)
PB17 L1ST3, (MMC2_CLK, IDE!)
PC4 L1RSYNCA
PC15 L1TXDB, L1ST5, DREQ1 (IDE!, )
+Nokia:
PA7 L1RCLKA, CLK1, TIN1, BRGO1 (MMC_ DO)
PB18 L1ST2, RTS2
PB19 L1ST1 (MMC_ DI)
PB22 L1SYNCB, SMSYN2, SDACK2 (MMC_CLK)
PB23 L1RSYNCB,SMSYN1, CTS3, SDACK1 (MMC_CS, IDE!)
Günther
Developer
Beiträge: 587
Registriert: Freitag 9. September 2005, 21:48

Beitrag von Günther »

Mhm, wie mir scheint kann man mit dem TDMA auch nicht auf ein Syncbyte lauschen, sondern nur mittels einem externen sync synchronisieren. Ausserdem sieht es so aus, dass ein Timeslot nur 16 Bytes groß sein kann. Dann müßte man 32 Einträge im Serial Interface RAM Entries erstellen, um die 512 Datenbytes zu bekommen. :cry:

Vielleicht dann doch gleich den SMC2 im NMSI und Transparent Mode (16.11.7) mit folgenden Pins verwenden:
PA8 SMTXD2 (MMC2_DI)
PA9 SMRXD2 (MMC2_DO)
PA7 CLK1, BRGO1 (MMC_ DO)
PB22 SMSYN2 (MMC_CLK)

Was mich allerdings noch wundert ist, das hier eine 8-bit Sync angepriesen wird, dieses aber später nicht mehr beschrieben wird (nur beim SCCx) und es dieses somit wohl für den SMC2 auch nicht gibt :gruebel: :gruebel:

Frage ist jetzt natürlich, wie man am besten den Sync macht (wie ist das überhaupt gemeint, ist der Sync -Port auf Ausgang oder Eingang eingestellt, bzw. warum kann man keinen CLK-Master definieren :gruebel: . ).
Günther
Developer
Beiträge: 587
Registriert: Freitag 9. September 2005, 21:48

Beitrag von Günther »

DBoxBaer hat geschrieben: So oder so: Wenn jemand eine Idee hat (und erklären kann...), wie
die CPU IRGENDWIE Daten über nen SCC oder sonstwo in brauchbaren
Geschwindigkeiten (>10MBit/s) transportieren kann, kann ich/man das mit
dem CPLD bestimmt umsetzen.
)
Sollte eigentlich machbar sein (siehe oben), kommt wohl nur auf die PINs an, die dem IDE zur verfügung stehen. SCC2 im Transparent und NMSI Mode wäre eine feine Sache - wenn man die Pins TXD2 und RXD2 zur Verfügung hat :cry: . Über den Buffer Descriptor kann man dann auf die Tx und Rx Buffer im normalen Speicher zeigen, und der Rest macht dann der SCC (bis zu 0xFFFF Bytes als Burst glaub ich ). Das sollte die CPU schon ein bisschen entlasten :wink:
Günther
Developer
Beiträge: 587
Registriert: Freitag 9. September 2005, 21:48

Beitrag von Günther »

PS. Vielleicht sollten wir damit besser in die Treiber-Ecke verschwinden - um die anderen nicht unnötig zu verwirren :D
saruman
Erleuchteter
Erleuchteter
Beiträge: 682
Registriert: Samstag 13. Juli 2002, 10:05

Beitrag von saruman »

Günther hat geschrieben:PS. Vielleicht sollten wir damit besser in die Treiber-Ecke verschwinden - um die anderen nicht unnötig zu verwirren :D
Schon lange geschehen... :gruebel: :D
Günther
Developer
Beiträge: 587
Registriert: Freitag 9. September 2005, 21:48

Beitrag von Günther »

Hier nur mal meine Idee zum SMC-Treiber. Habe es noch nicht getestet (muss noch umlöten und bräuchte noch ein Logic-Analyzer zum testen, ohne den wird es wohl nicht gehen. Mit dem Parallelport vom PC soll man sich ja was basteln können ;), mal schaun wann ich dazu komme ). Das ganze kann noch mit Interrupt (ISR) verfeinert werden, zum Testen habe ich das aber erstmal aus dem Code rausgenommen.

Ist nur bisher nur eine Design-Studie, aber wenn jemand Lust hat kann er ja mal anfangen zu testen, ich komme die nächsten Tage wohl nicht dazu...

Code: Alles auswählen


/*
ports used for this driver:
PA8 SMTXD2 (MMC2_DI)
PA9 SMRXD2 (MMC2_DO)
PA7 CLK1, BRGO1 (MMC_ DO)
PB22 SMSYN2 (MMC_CLK)
*/

#define NUMBER_OF_BURST_BYTES 512
#define SLOW_SPI_IO_CLK 1000
//////////////////////////////////////////////////////////
//////////////////////////////////////////////////////////
// low-level driver 
//////////////////////////////////////////////////////////
//////////////////////////////////////////////////////////
unsigned char test_buffer_rx[NUMBER_OF_BURST_BYTES+10];
unsigned char test_buffer_tx[NUMBER_OF_BURST_BYTES+10];
// general port definition
#define PAPAR (((iop8xx_t *) &immap->im_ioport)->iop_papar)
#define PADIR (((iop8xx_t *) &immap->im_ioport)->iop_padir)
#define PAODR (((iop8xx_t *) &immap->im_ioport)->iop_paodr)
#define PADAT (((iop8xx_t *) &immap->im_ioport)->iop_padat)

#define PBPAR (((cpm8xx_t *) &immap->im_cpm)->cp_pbpar)
#define PBDIR (((cpm8xx_t *) &immap->im_cpm)->cp_pbdir)
#define PBODR (((cpm8xx_t *) &immap->im_cpm)->cp_pbodr)
#define PBDAT (((cpm8xx_t *) &immap->im_cpm)->cp_pbdat)

// Pin connection definition
#define SD_DO  0x0040 // GPIO A, on SD/MMC card pin 7
#define SD_DI  0x0080 // GPIO A, on SD/MMC card pin 2
#define SD_CLK 0x0100 // GPIO A, on SD/MMC card pin 5
#define SD_CS  0x0200 // GPIO B, on SD/MMC card pin 1

#define SMC_CLK_SET_HIGH (PADAT |=  SD_CLK )
#define SMC_CLK_SET_LOW  (PADAT &= ~SD_CLK )

#define SMC_DI_SET_HIGH  (PADAT |=  SD_DI  )
#define SMC_DI_SET_LOW   (PADAT &= ~SD_DI  )

#define SMC_CS_SET_HIGH  (PBDAT |=  SD_CS  )
#define SMC_CS_SET_LOW   (PBDAT &=  ~SD_CS  )

#define SMC_DO_IS_SET  ((PADAT & SD_DO)?0x01:0x00) 
///////////////////////////////////////////
//#define SMC_ENABLED

//(((cpm8xx_t *) &immap->im_ioport)->iop_papar)
// DPRAM SMC

#define DPRAM_BASE (&immap->im_cpm.cp_dpmem)
#define RX_BD_STATUS  *((unsigned short*)(DPRAM_BASE +0x00))
#define RX_BD_LENGTH  *((unsigned short*)(DPRAM_BASE +0x02))
#define RX_BD_POINTER *((unsigned int*)  (DPRAM_BASE +0x04))
#define TX_BD_STATUS  *((unsigned short*)(DPRAM_BASE +0x10))
#define TX_BD_LENGTH  *((unsigned short*)(DPRAM_BASE +0x12))
#define TX_BD_POINTER *((unsigned int*)  (DPRAM_BASE +0x14))
// SMC Parameter RAM Memory MAP
#define SMC2_BASE ((&immap->im_cpm.cp_dparam)+0x0380) 
#define RBASE *((unsigned short*)(SMC2_BASE + 0x00))
#define TBASE *((unsigned short*)(SMC2_BASE + 0x02))
#define RFCR  *((unsigned char*) (SMC2_BASE + 0x04))
#define TFCR  *((unsigned char*) (SMC2_BASE + 0x05))
#define MRBLR *((unsigned short*)(SMC2_BASE + 0x06))
// Clock
#define BRGC1  (immap->im_cpm.cp_brgc1)
// Interrupts
#define CPCR   (immap->im_cpm.cp_cpcr)
#define CIMR   (immap->im_cpic.cpic_cimr)
#define CICR   (immap->im_cpm.cpic_cicr)
// SMC TRANSPARENT
#define SMCMR  (immap->im_cpm.cp_smc[1].smc_smcmr)
#define SMCM   (immap->im_cpm.cp_smc[1].smc_smcm)
#define SMCE   (immap->im_cpm.cp_smc[1].smc_smce)
#define SIMODE (immap->im_cpm.cp_simode)
#define SDCR   (immap->im_siu_conf.sc_sdcr)
////////////////////////
// Module definition
//#define SMC_ISR_ENABLED
#define SMC_TIMEOUT 999999

// SMC commands
#define SMC_IS_READ_BUSY    RX_BD_STATUS & 0x8000
#define SMC_SET_RX_BD_READY RX_BD_STATUS |= 0x8000

#define SMC_SET_SYNC        SMC_CS_SET_HIGH    
#define SMC_CLEAR_SYNC      SMC_CS_SET_LOW   

#define SMC_START_SMC_RX    SMCMR |=  0x0001
#define SMC_STOP_SMC_RX     SMCMR &= ~0x0001

#define SMC_START_CLOCK     BRGC1 |=  0x00010000
#define SMC_STOP_CLOCK      BRGC1 &= ~0x00010000
////////////////////////////////////////////
static int mmc_hardware_init(void) {
	volatile cpm8xx_t *cp  = (cpm8xx_t *) &immap->im_cpm;
	volatile iop8xx_t *cpi = (iop8xx_t *) &immap->im_ioport;

	printk("mmc2: Hardware init\n");
    //          PA8     SMTXD2          (MMC2_DI)
	cpi->iop_papar &= ~(SD_DI);
	cpi->iop_padir |=   SD_DI;
    //          PA9     SMRXD2          (MMC2_DO)
	cpi->iop_papar &= ~(SD_DO);
	cpi->iop_paodr &= ~(SD_DO);
	cpi->iop_padir &=  ~SD_DO;
    //          PB22    SMSYN2          (MMC_CLK)
	cp->cp_pbpar &=   ~(SD_CS);
	cp->cp_pbodr &=   ~(SD_CS);
	cp->cp_pbdir |=    (SD_CS);
    //          PA7     CLK1,  BRGO1    (MMC_ DO)
	cpi->iop_papar &=   ~(SD_CLK);
	cpi->iop_papar &=   ~(SD_CLK);
	cpi->iop_papar |=    (SD_CLK);

	// Clock + CS low
	cpi->iop_padat &= ~(SD_CLK);
	cp->cp_pbdat   &= ~(SD_CS);   // CS low???
	//cp->cp_pbdat   |= (SD_CS);   // CS low???
	cpi->iop_padat &= ~SD_DI;
	return 0;
}

void mmc_smc_port_init(void)
{
    /* 1. Configure the port B pins to enable the SMTXD2, SMRXD2, and SMSYN2 pins. Write PAPAR/PBPAR bits 8, 9, and 22 with ones and then PADIR / PBDIR and PAODR / PBODR bits 8, 9, and 22 with zeros.*/
    //          PA8     SMTXD2          (MMC2_DI)
    //          PA9     SMRXD2          (MMC2_DO)
    PAPAR |=  (SD_DO | SD_DI);
    PAODR &= ~(SD_DO | SD_DI);
    PADIR &= ~(SD_DO | SD_DI);

    //          PB22    SMSYN2          (MMC_CLK)
    PBPAR |=  SD_CS;
    PBODR &= ~SD_CS;
    PBDIR &= ~SD_CS;
    //SMC_CLEAR_SYNC;   

    /* 2. Configure the port A pins to enable BRG. Write PAPAR bit 7 with a one and PADIR bit 7 with a one. */
    //          PA7     CLK1,  BRGO1    (MMC_ DO)
    PAPAR |=  SD_CLK;
    PADIR |=  SD_CLK;
    PAODR &= ~SD_CLK;
}

void mmc_smc_hardware_init(void)
{
    /* 3a. Configure the BRG1. Write 0x00000006 to BRGC1. The DIV16 bit is not used and the divider is 3 (= 22Mhz) . */
    //BRGC1 = 0x00000006;
    //BRGC1 = 0x00000101; // we start with a very slow bit rate 66Mhz/16/128  = 32kHz ;)
    BRGC1 = 0x00001001;   // we start with a very slow bit rate 66Mhz/16/2048 =  2kHz ;)

    /* 3b. Connect the BRG1 clock to SMC2 using the serial interface. Write the SMC2 bit in SIMODE with a 0 and the SMC2CS field in SIMODE register with 0x000. */
    SIMODE &= ~0xF0000000;

    /* 4. Write RBASE and TBASE in the SMCx parameter RAM to point to the RX buffer descriptor and TX buffer descriptor in the dual-port RAM. Assuming one RX buffer descriptor at the beginning of the dual-port RAM and one TX buffer descriptor following that RX buffer descriptor, write RBASE with 0x2000 and TBASE with 0x2008. */
    RBASE = (unsigned short)(DPRAM_BASE +0x00);
   TBASE = (unsigned short)(DPRAM_BASE +0x10);

    /* 5. Program the CPCR to execute the INIT RX AND TX PARAMS command of SMC2. Write 0x00D1 to the CPCR. */
    CPCR = 0x00D1;

    /* 6. Write 0x0001 to the SDCR to initialize the SDMA configuration register. */
    SDCR = 0x0001;

    /* 7. Write 0x18 to RFCR and TFCR for normal operation. */
    RFCR = 0x18;
    TFCR = 0x18;

    /* 8. Write MRBLR with the maximum number of bytes per receive buffer. Assume 512 bytes, so MRBLR = 0x0200. */
    MRBLR = NUMBER_OF_BURST_BYTES;

    /* 9. Initialize the RX buffer descriptor and assume the RX data buffer is at 0x00001000 in main memory. Write 0xB000 to RX_BD_Status, 0x0000 to RX_BD_Length (optional), and 0x00001000 to RX_BD_Pointer. */
    RX_BD_STATUS =  0x3000;
    RX_BD_LENGTH =  NUMBER_OF_BURST_BYTES;
    RX_BD_POINTER = (unsigned int)test_buffer_rx;

    /* 10.Initialize the TX buffer descriptor and assume the TX data buffer is at 0x00002000 in main memory and contains five 8-bit characters. Write 0xB800 to TX_BD_Status (ready, final buffer,interrupt, Last in Message), 0x0005 to TX_BD_Length, and 0x00002000 to TX_BD_Pointer. */
    TX_BD_STATUS  =  0x3800;
    TX_BD_LENGTH  =  NUMBER_OF_BURST_BYTES;
    TX_BD_POINTER =  (unsigned int)test_buffer_tx;

    /* 11.Write 0xFF to the SMCE-Transparent register to clear any previous events. */
    SMCE = 0xFF;

    /* 14.Write 0x3830 to the SMCMR to configure 8-bit characters, unreversed data, and normal operation (not loopback). Notice that the transmitter and receiver have not been enabled yet. */
    SMCMR = 0x3930;  // reverse mode!!!!   
    //SMCMR = 0x3830;  //    
}

int mmc_smc_read(char* buffer, unsigned int length)
{
    int timer = 0;
    
    MRBLR = length;
    // init rx buffer
    RX_BD_POINTER = (unsigned int)buffer;
    RX_BD_LENGTH  = length;
    SMC_SET_RX_BD_READY;  // ready buffer    

    SMC_SET_SYNC;
    SMC_START_SMC_RX;
    SMC_START_CLOCK;
    SMC_CLEAR_SYNC; // SMC does start on the sync edge, so we could clear it aftwards anytime

    while ( SMC_IS_READ_BUSY && timer++ < SMC_TIMEOUT);   // wait for 

    SMC_STOP_CLOCK;
    SMC_STOP_SMC_RX;
    
    return (timer);
}

//////////////////////////////////////////////////////////
//////////////////////////////////////////////////////////
// High-level driver 
//////////////////////////////////////////////////////////
//////////////////////////////////////////////////////////
static int mmc_read_block(unsigned char *data, unsigned int src_addr)
{
...
#if SMC_ENABLED
    mmc_smc_port_init(); // Init HW for SMC
    i=mmc_smc_read(data,NUMBER_OF_BURST_BYTES);
    mmc_hardware_init(); // Init HW for bit banging 
#else
	for (i = 0; i < 512; i++) data[i] = mmc_spi_io(0xff);
#endif
...
}

static int mmc_init(void)
{
	int rc;

#ifdef SMC_ENABLED    
    mmc_smc_hardware_init();
#endif    
	rc = mmc_hardware_init();

...
}

Habe das File mal als mmc3test.c (diesmal ins Head 8)) eingecheckt. Das File sollte nur als Testversion zum Hacken verwendet werden, siehe auch Header . Das gibt aktuell noch ein Zuweisungfehler,habe nur vergessen den Kommentar wieder zu entfernen, da ich gerade keine Zeit mehr hatte:cry::
RBASE = (unsigned short)(DPRAM_BASE +0x00);
TBASE = (unsigned short)(DPRAM_BASE +0x10);
Günther
Developer
Beiträge: 587
Registriert: Freitag 9. September 2005, 21:48

Beitrag von Günther »

Hat jemand eine Ahnung ob der BRGC1 schon irgendwo verwendet wird?

Wenn ich das BRGC1-Register beschreibe schmiert die Kiste ab. Das BRGC2-Register scheint zu klappen. Ich bräuchte aber den BRGC1 wegen dem Port PA7.

Code: Alles auswählen

static cpm8xx_t	*cpmp = (cpm8xx_t *)&(((immap_t *)IMAP_ADDR)->im_cpm);
	volatile cpm8xx_t	*cp;
	cp = cpmp;
	cp->cp_brgc1 = 0x00000101;
Der BRGC1 ist auch noch auf PB27 verfügbar , vielleicht liegt es ja daran. Weiss jemand für was dieser Port gebraucht wird?
In der Console kommt beim Booten:

Code: Alles auswählen

ttyS0 at 0x0280 is on SMC1 using BRGttyS1 at 0x0380 is on SMC2 using BRG2
Welcher Treiber ist das und kann das abgestellt werden???

Ohne BRGC1 leider keine SMC2 Optimierung :(

Danke
Günther
Carjay
Developer
Beiträge: 122
Registriert: Sonntag 23. April 2006, 12:37

Beitrag von Carjay »

PB27 ist SDA vom I2C.

Und der Treiber ist der für die seriellen Schnittstellen (Nullmodem und Modem).
Günther
Developer
Beiträge: 587
Registriert: Freitag 9. September 2005, 21:48

Beitrag von Günther »

Carjay hat geschrieben:PB27 ist SDA vom I2C.

Und der Treiber ist der für die seriellen Schnittstellen (Nullmodem und Modem).
Ist der Treiber den für das Modem aktiv, vermute ja das dieser den SMC2 benutzt??? Aber kann ja eigentlich nicht, weil die Ports ja bereits erfolgreich für den MMC treiber verwendet wird . Aber ev. kommen sich die Treiber beim SMC in die Quere. Kann man das irgendwie abschalten?

Wird der IC2-bus den aktiv benutzt (bzw. der BRGC1) ?
Günther
Developer
Beiträge: 587
Registriert: Freitag 9. September 2005, 21:48

Beitrag von Günther »

Mhhhm, also der BRGC1 wird wohl definitiv benutzt und zwar von der MMI. Wenn ich diesen abschalte geht telnet und die console nicht mehr (box reagiert auch nicht auf Ausknopf), wenn ich die Baudrate nur runterdrehe geht zwar noch telnet (und der Ausknopf) aber die console zeigt lustige Zeichen an.

Weiss jemand auf die Schnelle, welches Modul den BRGC1 initialisiert und ob ev. der BRGC3 oder 4 dafür benutzt werden kann? (Der BRGC2 ist mit den selben Daten initialisiert wie der BRGC1, wird also wahrscheinlich auch benutzt)

Danke
Günther
Günther
Developer
Beiträge: 587
Registriert: Freitag 9. September 2005, 21:48

Beitrag von Günther »

So, das Problem mit dem benutzen BRGC1 habe ich in den Griff bekommen. In .config nur den SMC deaktivieren (//CONFIG_8xx_SMC2=y) und dann noch schnell uart.c gepatched:

int __init rs_8xx_alloc_brg(int port)
{
static int brg = 1;
...
}

static int __init serial_console_setup(struct console *co, char *options)
{
...
m8xx_cpm_setbrg((ser - rs_table)+1, bd->bi_baudrate);
...
}

Und schon ist der BRGC1 frei ;)

In Tippelschritten geht es weiter ...