Rockbox Development > New Ports
SanDisk Sansa c200v2, m200v4, clipv1, clipv2, clip+, and fuzev2
FlynDice:
Just a little update on progress (or lack thereof) for for me with the clip+.
I have found that I only need to disable the Dcache. The player boots up fine with just the Icache and mmu enabled. I have not played around with the memory mapping and cacheable areas yet but will get there eventually. The problem with the dcache enabled has been getting the SD card past the ident state while initializing. For some reason the card is sending back an rca of 0x0000XXXX. I can get it past there to the STBY state by issuing a second SD_SEND_RELATIVE_ADDR command, but then I cannot get it to TRAN state with a SD_SELECT_CARD cmd.
While investigating the Dcache I found that the 926ejs has a test & clean cache coherency function that may come in useful later. It seems it knows if the cache is dirty and will loop until clean.
I have found a spot(0x6464) in the of's send_cmd function that sets or unsets B5 depending on the disk but I haven't been able to see a difference when I've used it.
As far as clocks go, the plla/b registers are different but it seems most all of the rest of the clock registers still use bits 1:0 as clock select and most are set to 1 for plla. CGU_INTCTRL (offset 0x20) seems it may be different from as3525v1 as it is also has 1 stored to it but that is a read only bit for CGU_INTCTRL in the as3525v1. I think the CGU_PROC register is the same as v1 and the dividers work just like the v1.
funman:
Perhaps B5 is to select internal/µSD ?
I don't remember seeing a different base address like (there are 2 PL180 controllers in the AS3525v1), and MCI_HCON only reports 1 card present.
The code is a bit after a read of GPIOA A2 which is tells if an µSD card is present.
About CGU_PROC here is what I found:
* I commented out the code touching it in system_init() because it would prevent boot
* I've found a function which only touches bits 7:4 / or bits 3:0, so the register looks very much like AS3525v1 : divider on 7:4, pre-divider on 3:2, and clk_sel on 1:0 (at 0x236C in Clip+)
C code of that function (I simplified the setting of CGU_* by setting only the divider bits, other bits are not modified):
--- Code: ---static inline void delay(void) { int i = 40; while(i--) ; }
void mod_cgu (void)
{
max_div_peri = ((peri_setting >> 2) & 0xf) + 1;
min_div_proc = ((proc_setting >> 4) & 0xf) + 1;
div_proc = min_div_proc * max_div_peri;
if(div_proc > 0xf)
div_proc = 0xf;
if(min_div_proc > 0xf)
min_div_proc = 0xf;
CGU_PROC = (proc_setting & 0xf) | ((div_proc - 1) << 4);
delay();
int div_peri = 1;
/*
* pclk: faster -> slower
* fclk: slower -> faster
*/
while(div_proc > min_div_proc && div_peri < max_div_peri)
{
if(div_peri < max_div_peri)
{
CGU_PERI_DIV = div_peri; /* bits 7:2 */
delay();
div_peri++;
}
if(div_proc > min_div_proc)
{
CGU_PROC_DIV = (div_proc - 2); /* bits 7:4 */
delay();
div_proc--;
}
}
}
--- End code ---
Perhaps tuning some delays might make the Clip+ boot with modified (= faster ?) CGU_PROC
BTW 0x0000XXXX is correct for RCA, it is a 16 bits register.
Though it's OK to store it on 32 bits, because all (?) commands needing RCA as an argument only need "stuff bits" as 31:16
FlynDice:
--- Quote from: funman on March 13, 2010, 05:48:43 AM ---Perhaps B5 is to select internal/µSD ?
--- End quote ---
Yes this is what I think also.
--- Quote from: funman on March 13, 2010, 05:48:43 AM ---I don't remember seeing a different base address like (there are 2 PL180 controllers in the AS3525v1), and MCI_HCON only reports 1 card present.
--- End quote ---
I think the MCI_HCON value is reporting 2 cards. Look at the HCON_NUM_CARDS macro in the linux patch.
--- Quote from: funman on March 13, 2010, 05:48:43 AM ---BTW 0x0000XXXX is correct for RCA, it is a 16 bits register.
--- End quote ---
But the RCA is the 16 MSB and if it sends 0x0000XXXX then it's using an RCA of 0x0000 which is not going to work for the SD_SELECT_CARD cmd. Using an RCA of 0 for the SD_SELECT_CARD cmd actually deselects the card.
funman:
--- Quote from: FlynDice on March 13, 2010, 08:33:50 AM ---
--- Quote from: funman on March 13, 2010, 05:48:43 AM ---BTW 0x0000XXXX is correct for RCA, it is a 16 bits register.
--- End quote ---
But the RCA is the 16 MSB and if it sends 0x0000XXXX then it's using an RCA of 0x0000 which is not going to work for the SD_SELECT_CARD cmd. Using an RCA of 0 for the SD_SELECT_CARD cmd actually deselects the card.
--- End quote ---
Oops right.
I just tried a build with only dcache disabled, and I'm printing the RCA.
It alternates between 0x0 and 0xD555 .. weird. Perhaps we need to loop until we receive a correct RCA ?
EDIT: I tried to print the CID, and there is only one 32 bits word set: 0xC0FF8000 which is the response to the previous command.
So it looks like the responses are late / or stay in the register for too long / or we read them too quickly (much likely)
EDIT2: Fixed (in svn) : I added a (probably much too long) delay before reading response and my Clip+ boots fine with both caches ON.
The delay can certainly be lowered, right now boot time is quite much longer than before (although should not be more than 4 seconds: 2 in bootloader, 2 in rockbox.sansa).
Now internal storage works (please report bugs), let's focus on sound and µSD !
It'd be nice to know if this code also works on Clipv2
FlynDice:
@funman:
SD seems to work great now with both caches enabled.
I have been struggling with the CGU_PERI clock select register for awhile. For some reason b 1:0 are being cleared and I cannot find where this is happening in our code. I tried to put a panic right after it gets set in system-as3525.c to be sure it was being set correctly but I get a dark screen that won't recover. I'm wondering if this is some sort of fallback that the chip does on it's own if the settings are screwed up a bit, ie going to a safe 24 MHz frequency with clk_main?
The radio seems to work. I can scan channels and it seems to find the right presets and the mode will change from stereo to mono if i unplug the headphones.
I will post a patch with some cache coherence functions that take advantage of the test & clean function that the 926ejs has available. They are supposedly more efficient than the regular arm cache coherence functions and I did find some versions in the OF. They are much simpler, you don't need to supply a range, it can tell if the cache is dirty and just cleans it until there are no more dirty lines. See p2-23 of the ARM926EJ-S TRM.
I'll look at adding the LP bits to MCI_PWREN, adding HS, and 4bit bus and see how things work.
In the linux patch there is some info on the AS3543 vs the AS3514, It looks quite similar but I have not really studied it yet. Maybe a clue or 2 for sound?
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version