Rockbox Development > New Ports
SanDisk Sansa c200v2, m200v4, clipv1, clipv2, clip+, and fuzev2
mc2739:
--- Quote from: funman on March 20, 2009, 12:18:03 PM ---@mc2739
Did the test fail before using this patch ?
--- End quote ---
Yes, it did fail before the patch was applied.
--- Quote from: kugel. on March 20, 2009, 12:27:52 PM ---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").
--- End quote ---
My e260v2 acts the same. Under System->Rockbox info it shows the correct size (3.79GB), but under System->Debug->View disk info it shows Blocks: 0x0011E9E00. There is also some other info on the View disk info screen that looks wrong.
sko:
--- Quote from: kugel. on March 20, 2009, 12:27:52 PM ---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").
--- End quote ---
Same on my e250v2: System->Rockbox info shows 1.88GB (correct), System->Debug->View disk info shows Blocks: 0x001E9E00.
FlynDice:
e280v2: : System->Rockbox info shows INT: 7.18GB/7.62GB, MSD: 3.50GB/7.45GB. System->Debug->View disk info shows Blocks: 0x001E9E00 for internal and 0x00eef000 for msd card.
As far as mmu goes here's some commented disassembly(e200), see what you can make of it...
http://pastie.org/422828
EDIT: whoops 0x300<<2 = 0xc00 not 0x30000....
EDIT: Well that makes more sense now. Looks like the OF makes the 1MB sections at 0x00000000 and 0x30000000 writeback cacheable and the rest non cacheable. The other difference I noticed are the access pemissions in the tags. The OF uses a c value(11 permission bits) and the other rockbox arm mmu routines seem to use a 4 (01 supervisor r/w, user r only). Would someone who actually knows what they're doing take a look and comment... ;)
EDIT: I cloned a bit of kugel's debug code to work on the mmu. here's a diff to make the mmu info come up under debug View HW info
EDIT:I've put the TTB_BASE at 0x307fc000 to mimic the of and actually read the values in the table to see if they were set up right. They appear to be fine. I found I can enable write-back cache on the 1 MB sector at 0x00000000 with no ill effects but if I try to enable writeback on the 1MB section at 0x30000000 I get a mirror image display. Rockbox appears to be operating as the lcd screen dims and comes back with wheel/button input. After the second time it dims the lcd comes back with non mirrored message :
No partition
found.
Insert USB cable
and fix it.
which seems to be from main.c where it can't mount any disks.
funman:
Hello,
I investigated the "disk" problem on my Fuze, and I think it is more a memory problem rather than SD problem.
I launched the md5sum plugin on the whole disk, and absolutely all sums were right (even for the bitmaps which are wrongly displayed)
I bought a Sansa Clip to see if I could see any differences between the 2 models, but it turned out to be a Clipv2 !
Note that it's a 1GB model in the new packaging, which makes wrong the assumption that v2 models are only 4GB or 8GB.
I started working on the Clipv2 then : see the patch on FS#10047 (mkamsboot+bootloader)
pbxy : I looked at the LCD code and the LCD commands themselves are 100% identical to the Clipv1. I found the same differences than you:
* GPIO*_AFSEL registers are not modified
* GPIOB_PIN2 is the D/C#pin
* DBOP settings are different from Clipv1 settings
I downloaded your patch and I'll read it at home.
I remember the Clipv1 needs a GPIO pin to be set to work at all (probably the pin powering the screen) and this pin wasn't set in the LCD code, but in hardware initialisation routines.
I looked at these routines to find something similar but I was afraid ..
The Clipv2 uses I2C on something else than the AS3514 : with I2C_TESTOUT2 (0xC8070058) & I2C_TESTIN registers:
* bit 0 of testin is sda input
* bit 0 of testout is sda output
* bit 1 of testout is direction (set = output, unset = input)
* bit 2 of testout is scl
It seems that this i2c communication is used on registers not present in AS3514 (0x12, 0x17 which is USB_UTIL in as3514, 0x18 to 0x1f but not 0x1d)
Perhaps on these registers is a LCD_enable bit.
Else the Clipv2 OF looks like it uses an extended AS3525 : it's an armv5t since the BLX instruction is used, and use some registers undocumented in AS3525 pdf (like 0xC6070000 marked as "reserved"; or too big offsets like [something_BASE,#0x40] where registers stop at #0x30)
Perhaps finding which SoC it uses and if the i2c registers are documented would help activating the LCD (and next steps).
See you
FlynDice:
I think I've got the mmu working but it makes the main program choke while trying to mount disks. I put a patch on flyspray so hack away.
http://www.rockbox.org/tracker/task/10048
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version