Rockbox Development > New Ports
SanDisk Sansa c200v2, m200v4, clipv1, clipv2, clip+, and fuzev2
saratoga:
--- Quote from: FlynDice on March 15, 2009, 01:37:00 AM ---Do you have a suggestion for determining if whether or not the mmu and Dcache are actually working besides a noticeable speed difference?
--- End quote ---
Can the MMU mirror memory? You could setup a duplicate copy of the main memory at some other address and then see if it exists. If not, you could try remapping memory, but that could cause its own set of crashes.
--- Quote from: pbxy ---I tested most of GPIOA and B with C6 as output, but no button presses were detected. I tested using the "delay method".
--- End quote ---
The ClipV2 is believed to use a different CPU then the V1, so the GPIO addresses may not even be at the same addresses in memory. You should ask Bagder to request a copy of the AS3536 datasheet. Otherwise, you'll have to dig through the retail firmware looking for GPIO registers.
Edit:
I looked at the V2 clip firmware, and its got the string "AS3525_2_0 " just like the V1. funman said he saw ARMv5 ops in the firmware file, so I checked, and there are v5 ops. That would imply that its not a 3525 (ARMv4), but i see a few in the ClipV1 firmware too (things like "stc2 7, cr15, [ip, #888]").
Is it possible theres dead code in there meant for different AMS chips, and that we're actually still dealing with an AS3525 on the V2?
kugel.:
--- Quote from: FlynDice on March 15, 2009, 01:37:00 AM ---Yes I guess I'm getting caught in the enabled vs functioning trap. When I disable the Icache it behaves identically to what happens when I enable the mmu.
I'll start looking at the "Program level 1 and level 2 page tables as required" middle step and see what I can see...
Do you have a suggestion for determining if whether or not the mmu and Dcache are actually working besides a noticeable speed difference?
--- End quote ---
Is this still with bertriks patch? Because I didn't manage to enable the MMU.
--- Quote from: pbxy ---Hi again,
I patched mkamsboot and I can now run custom code on my Clip v2. Smiley
--- End quote ---
Great success, good job! Is there a recovery method on the v2 clip, or did you just hope to not brick your clip entirely? I'll have a look at your patch.
pbxy:
--- Quote from: kugel. on March 15, 2009, 08:36:22 AM ---Is there a recovery method on the v2 clip, or did you just hope to not brick your clip entirely? I'll have a look at your patch.
--- End quote ---
I have not discovered any recovery method yet, I just tried to make sure the OF is still able to boot when the button checks fail.
So I was hoping the hardware would be similar enough to the v1 to run the code and unpack the OF.
Apart from that I think it was important to raise the DRAM_SIZE value from 0x50000 to 0x200000, because the unpacked OF is bigger (0x5fa7c).
--- Quote from: saratoga on March 15, 2009, 02:07:52 AM ---The ClipV2 is believed to use a different CPU then the V1, so the GPIO addresses may not even be at the same addresses in memory.
--- End quote ---
The USB "button press" on A6 gets detected if USB is plugged in, so at least the GPIO address/pin combination for this is equivalent to the v1.
After the USB check code I tried several Cx-output/Bx-input combinations for the following button check.
EDIT (2009-03-16, 01:32): I found the power button on A7 like in the clip v1, and I'm using it now to boot the OF (my current mkamsboot/dualboot is attached).
Now I'm trying to get the display in the rockbox bootloader to work. In the OF (still v02.01.32) there's the display initialization function beginning at address 0x73E0 (counted without fw file header).
It uses almost exactly the same order of commands (0xd5, 0x10, 0xdb, 0x34, ...) as the clip v1 display driver in rockbox (lcd_init_device() in firmware/target/arm/as3525/sansa-clip/lcd-ssd1303.c).
Only the lcd_write_command(LCD_SET_COM_OUTPUT_SCAN_DIRECTION_INV); (command 0xC8) is made 4 times instead of 1 in the OF.
The GPIO pins used in the OF also differ from v1. In the display initialization there are GPIOB{1,2,3,5,7} and GPIOA5 set as outputs and set to different values.
In the function which seems to write the display commands (beginning at address 0x7238) there are also different values for DBOP_CTRL (0x51004), DBOP_TIMPOL_01 (0x36A12F) and DBOP_TIMPOL_23 (0xE0370036).
Additionally at the end of this function, DBOP_CTRL is again set to 0x51004 and DBOP_TIMPOL_23 is set to 0xE037E037.
I currently don't fully understand the OF's code, but I tried to adapt the differences in the rockbox clipv1 display driver. It's currently not working (nothing's shown on the display), but I'll attach it, too.
EDIT (2009-03-18, 01:41): Yay, visual feedback! Button light is on GPIOA_PIN(5).
FlynDice:
--- Quote from: kugel. on March 15, 2009, 08:36:22 AM ---Is this still with bertriks patch? Because I didn't manage to enable the MMU.
--- End quote ---
Ah see you got caught in the same semantics trap that I did. I have enabled the mmu but I do not have a functioning mmu. I have been playing around with the cache flag parameters handed to the map_section function from mmu-arm.S. I believe these are the cache flags from page 4-11,12 in the TRM. If I "enable" the mmu and use CACHE_NONE(0x0) for map_section I believe I get no mmu and no cache. However if I use 0xc(for cached writeback mode) I get a white lcd screen.. but very very quickly as if perhaps the mmu were working but theres a memory mapping problem(which is beyond my skills at this point...) Then again I could just be hoping.
EDIT: The more I read about setting up the translation tables and mapping the more I think that is our problem here. Its as if we have a light switch and we've tossed some wire between the switch and a lightbulb and have been expecting the light to turn on just because we turned the switch on. I think if we set up the mapping correctly we get the mmu to operate.
Hillshum:
--- Quote from: saratoga on March 15, 2009, 02:07:52 AM ---The ClipV2 is believed to use a different CPU then the V1, so the GPIO addresses may not even be at the same addresses in memory. You should ask Bagder to request a copy of the AS3536 datasheet. Otherwise, you'll have to dig through the retail firmware looking for GPIO registers.
--- End quote ---
Didn't AMS make the datasheet public? There's a link in this thread somewhere...
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version