Rockbox Development > New Ports
SanDisk Sansa c200v2, m200v4, clipv1, clipv2, clip+, and fuzev2
kugel.:
--- Quote from: funman on March 20, 2009, 12:18:03 PM ---@Hillshum
I don't know how to verify if the cable is fine, but that could very well be the case.. I'll ask my friends to see if I can find a Sansa + a cable to see which one of the cable or the Fuze is damaged.
For now, I continue working with the microSD ;)
@mc2739
Did the test fail before using this patch ?
@kugel
How come the capacity is reported fine ?
The CSD reports 0x1E9E00 sectors on my Fuze and I remember that it was identical bit per bit for all e200 and Fuzes (even with different capacities).
Are you reading it from debugging > disk info ?
--- End quote ---
No, disk info still shows 0x1E900. I was looking under System->Rockbox info. It shows (apparently correctly) how much disk spaces is left and the total disk space (currently I have "141MB/3.79GB").
--- Quote ---I'm still looking at how to find the number of banks (4GB or 8GB), and if they are needed or not.
--- End quote ---
I'm assuming it's 1 bank for each 2GB (2GB is the maximum you can get with non-HC), although it would seem weird why the problems already start at 1GB. Maybe it's 1bank per 1GB, but then it would be weird why 2GB models don't have a bank.
BTW, I haven't exactly looked at your code. But it just works, what's the exact problem with the number of banks or do you have it hard-coded for 4GB?.
--- Quote ---If you can give me different CSDs with their model & capacity I could compare them with the one I have (I was reading the function which parses the CSD and I noticed some 'out of spec' fields!!)
--- End quote ---
Well, IIRC the v1 sansas don't have a CSD lookup table, if you mean that.
--- Quote ---By the way I tried to enable the MMU and noticed some problems:
- if I enable caching & buffering (flag 0xC) on IRAM I see crashes quickly after boot
- if I enable it on SDRAM I can not boot : the 1st sector (partition table) is incorrectly read
Flyndice: I looked (quickly, because I don't know anything about this stuff..) at the MMU code in the OF of Clip and Fuze and I see a strange thing:
- Clip OF enable caching only for the 1st MB of SDRAM (out of 2)
- Fuze OF enable caching onyl for the first 5 MBs of SDRAM (out of 8)
weird.. !
--- End quote ---
Interesting. Can I see the code? I haven't been able to boot at all (no apparent crash or partition error), just freeze when I tried.
Weird that it doesn't cache the whole ram. Maybe it doesn't cache its plugin memory (if they have one) or something. I'm unsure if we gotta do it in the same way.
funman:
--- Quote from: kugel. on March 20, 2009, 12:27:52 PM ---I'm assuming it's 1 bank for each 2GB (2GB is the maximum you can get with non-HC), although it would seem weird why the problems already start at 1GB. Maybe it's 1bank per 1GB, but then it would be weird why 2GB models don't have a bank.
--- End quote ---
Currently it's ~4GB per bank (just like e200v1) so 2GB or less models don't need switching
--- Quote from: kugel. on March 20, 2009, 12:27:52 PM ---BTW, I haven't exactly looked at your code. But it just works, what's the exact problem with the number of banks or do you have it hard-coded for 4GB?.
--- End quote ---
I have not hardcoded it, nor put any limit, so I thought testing would require formatting the storage with > 1GB partition and see if the FAT driver can access all the data.
Perhaps the reported size you see comes from the FAT32 header, I'll check that.
Right now we still need to find the 'disk' capacity.
--- Quote from: kugel. on March 20, 2009, 12:27:52 PM ---Well, IIRC the v1 sansas don't have a CSD lookup table, if you mean that.
--- End quote ---
I mean I need a CSD for various Sansa AMS (e200, Fuze, Clip, ..) with 1 or 2GB, 4GB and 8GB to see the differences.
--- Quote from: kugel. on March 20, 2009, 12:27:52 PM ---Interesting. Can I see the code? I haven't been able to boot at all (no apparent crash or partition error), just freeze when I tried.
Weird that it doesn't cache the whole ram. Maybe it doesn't cache its plugin memory (if they have one) or something. I'm unsure if we gotta do it in the same way.
--- End quote ---
Sorry I don't have it with me, I'll take the patch next time!
kugel.:
--- Quote from: funman on March 20, 2009, 12:38:21 PM ---Currently it's ~4GB per bank (just like e200v1) so 2GB or less models don't need switching
--- End quote ---
Then my fuze would only have 1 bank, and we wouldn't need switch. I don't quite understand.
funman:
We need to determine at runtime if the Sansa uses banks of 0x7A7800 sectors (~4GB) because 2GB and less models don't.
Then if it's 4GB or more we need to use a special command to enable access to the whole capacity of the bank.
If it's 8GB or more we need to determine the number of banks in this model (reading the OF it seemed only 1 or 2 banks was possible, this is why I was saying 4GB OR 8GB, and not 16GB; but this assumption might be wrong for newer models like Clipv2 or Fuzev2)
pbxy:
--- Quote from: funman on March 19, 2009, 09:45:44 AM ---If you need something else just ask !
--- End quote ---
Thanks for the button pins. All button except for left, select and right get detected now.
From button_init_device():
GPIOD_DIR &= ~((1<<2) | (1<<1) | (1<<0));
...
GPIOD_DIR |= ((1<<6) | (1<<5) | (1<<4));
I have a bigger problem with DBOP or the display controller. I can't spot any write to the GPIOx_AFSEL registers in the v2's OF.
In the v1 OF it is clearly visible before and after some writes into DBOP_TIMPOL_{01,23} and DBOP_CTRL.
In the v2 OF there's a silimar section writing into these registers (at 0x71d0), but there are no writes into *_AFSEL anywhere (except for one GPIOD_AFSEL = 0 somewhere else).
On the other hand it is clear DBOP is used, because the command write routine (0x7238) writes into DBOP_DOUT the same way the v1 OF does.
If the bits in the AFSEL registers are not set high, this would mean no GPIO pins are configured to be controlled by DBOP, right?
So the display controller had to be connected to the dedicated DBOP pins existing on the AS3525? I'm not sure about this,
because then I think the display commands should arrive without any further initialization.
I also noticed that the "fifo queue empty" bit in DBOP_STAT, which is looked at in lcd_write_command(), doesn't get set after writing a byte,
when the following commands are not executed in the initialization:
CGU_PERI |= 0x10000;
CCU_IO |= 1<<3;
CGU_DBOP |= 0x18;
Not all of them are necessarily relevant, but I didn't test it. At least, the fifo status bit gets cleared. Or may this be a bad sign?
I also guess that GPIOB_PIN(2) is the D/C# pin. "0xfb" is written to it in the write command function in the OF and "4" in
another one which may be the write data function. But there are also the pins B1, 3, 5 and 7 in the initialization:
GPIOB_PIN(1) = 0xFD;
GPIOB_PIN(2) = 1<<3;
GPIOB_PIN(5) = 0xDF;
GPIOB_PIN(7) = 0;
EDIT: added (dirty) lcd-ssd1303.c patch.
EDIT2: I cleaned the messy patch up and added the OF offsets where the different instructions were made, here it is.
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version