Rockbox Development > New Ports
SanDisk Sansa c200v2, m200v4, clipv1, clipv2, clip+, and fuzev2
Hillshum:
Could this be an issue with the RB bootloader? I never noticed it till a few days ago? If I could get my sansa to behave right now I'd try a clean firmware.
FlynDice:
I've been investigating the mmu for a few days along with the instruction & data caches and bus modes. Right now we are running with the mmu disabled and the instruction and data caches enabled, even though the Arm TRM says you shouldn't do that with the data cache. I'm basing my assertions on the values read from the control register used to enable/disable these features. The caches are enabled in the bootloader along with asynchronous bus mode and that carries through to the main rockbox. The strange thing is that if I enable the mmu it slows down rockbox which is quite opposite of what I would expect. Disabling the Dcache (since the mmu is not enabled) seems to have no effect good or bad that I can see yet(but maybe I don't know what I'm looking for...). I looked through the disassembly of the OF(e200v2) and found the mmu and cache functions along with functions to set the 3 bus modes. They all look similar to what we've got in mmu-arm.S. We can enable the mmu quite easily but there must be something that doesn't want to "play nicely" with our little friend here. Any chance our good old 1GB sd problem is related?
kugel.:
--- Quote from: FlynDice on March 15, 2009, 12:53:29 AM ---I've been investigating the mmu for a few days along with the instruction & data caches and bus modes. Right now we are running with the mmu disabled and the instruction and data caches enabled, even though the Arm TRM says you shouldn't do that. I'm basing my assertions on the values read from the control register used to enable/disable these features. The caches are enabled in the bootloader along with asynchronous bus mode and that carries through to the main rockbox. The strange thing is that if I enable the mmu it slows down rockbox which is quite opposite of what I would expect. Disabling the Dcache (since the mmu is not enabled) seems to have no effect good or bad that I can see yet(but maybe I don't know what I'm looking for...). I looked through the disassembly of the OF(e200v2) and found the mmu and cache functions along with functions to set the 3 bus modes. They all look similar to what we've got in mmu-arm.S. We can enable the mmu quite easily but there must be something that doesn't want to "play nicely" with our little friend here. Any chance our good old 1GB sd problem is related?
--- End quote ---
The datasheet doesn't only tell the "one shouldn't do that", but also that the dcache *cannot* be active without mmu somewhere.
I'm fairly sure the slowdown you're noticing is due to disabling the ICache too (because this matches my experiences), but feel free to prove the opposite with patches. I haven't managed to turn the mmu on yet.
Oh, and yes, the control register shows "true" for dcache, but I *really would not* rely on this register for reading the dcache status without mmu.
FlynDice:
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?
pbxy:
Hi again,
I patched mkamsboot and I can now run custom code on my Clip v2. :)
Luckily the dualboot.S code detects if USB is plugged in and switches to OF because GPIO mapping seems completely different from v1.
I tested most of GPIOA and B with C6 as output, but no button presses were detected. I tested using the "delay method".
Well, the rockbox bootloader for Clip v1 doesn't run either. At least there's nothing on the display.
My modifications to mkamsboot.c are attached. I also added header checksums check, a missing int cast and fixed a double free exception.
I'm currently using the "clip" rockbox bootloader target until there's something more appropriate available.
% ./mkamsboot ~/x/clip02.01.32/m30pa.bin ~/x/rockbox/bootloader-clip.sansa m30pa.bin
mkamsboot v0.1 - (C) Dave Chapman and Rafaël Carré 2008
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
[INFO] MD5 sum - 0ad3723e52022509089d938d0fbbf8c5
[INFO] Original firmware MD5 checksum match - Clip V2 2.01.32
[INFO] Patching Clip V2 firmware
[INFO] Original firmware size: 391804 bytes
[INFO] Packed OF size: 90807 bytes
[INFO] Bootloader size: 45068 bytes
[INFO] Packed bootloader size: 22732 bytes
[INFO] Dual-boot function size: 264 bytes
[INFO] UCL unpack function size: 168 bytes
[INFO] Total size of new image: 113971 bytes
*****************************************************************************
*** THIS CODE IS UNTESTED - DO NOT USE IF YOU CAN NOT RECOVER YOUR DEVICE ***
*****************************************************************************
pbxy
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version