Rockbox Development > New Ports
SanDisk Sansa c200v2, m200v4, clipv1, clipv2, clip+, and fuzev2
atomikpunk:
Ok, I'll try to look at buttons handling later today. I was looking for GPIOs but didn't see that in v1 it was on ADC.
For the LCD, I'm pretty sure I already found both of the write_command and write_data routines. I'll give it a deeper look later today. I also think that the v1 team already put up a basic lcd driver, so it probably only need some minor changes.
linuxstb:
It would be useful to work out the GPIOs anyway - it will be much easier if we can find at least one button detectable that way.
It would also be nice to work out what GPIOs are used for output - hopefully the button light or other LEDs (I don't know what's on the m200v2) are controlled via GPIO. This would be another nice way to get feedback from our test code.
P.S. The "v1 team" is just me...
atomikpunk:
Well I looked at the OF tonight, analyzed a bit more on the lcd drawing routines... I can confirm that I found the lcd_write_command and lcd_write_data routines, and also found where they draw at particular pixels in (x,y). Nothing more to report as of now, but a little more understanding ;)
But for the firmware "expansion" I'm still puzzled how we could do it. I'd say that just changing the size multiplier in the header would do, _for the firmware_. But it would break the OF because of absolute addresses in the libraries...
BTW, after review, it seems that the size multiplier in the header is only valid for the firmware section, that just happens to be the same size as "library blocks" on the FW I'm currently looking at... I still don't know how to deduce the library blocks size...
So I guess I'll take advice of my pillow for now ;D
Edit: I thought about it in my shower this morning, I guess that simply expanding the firmware section in the OF could in fact do the trick, because the hardcoded addresses are for the use of library blocks, but we won't use them anyway while running rockbox, so who care about bad addresses in blocks that won't get executed!
I'm also wondering, maybe that the library blocks are in fact "files" created on a "system partition" that hold particular algorithms, like codecs, etc. I wonder if we could put some extra rockbox object files and load them the same way the OF do with library blocks. So I guess another thing to look at in the disassembly is how they dynamically load (if that's the way they do it) library blocks, where they take it from, where they load it to, etc. In brief, how the "dynamic" library handling is done.
So to resume, my research on the OF disassembly is concentrated on:
- firmware file format
- how to expand the firmware
- GPIOs
- buttons
- "dynamic" libraries
atomikpunk:
Hi Daniel,
yes that would be very helpful if you could trace the buttons signals up to the processor. I work in electronics too so let me know if I can help you with that. If you don't mind checking for LEDs or stuff like that too, that'd be great.
beambot:
Hello Forum,
@atomikpunk , linuxstb
nice work till know. You worked out a lot of information about our new 'toy'
@linuxstb
Is it possible to give us more information about the memory mapping of the AS3525 out of the manual e.g adress range of GPIO , ROM, RAM , extRAM, Flash etc. Perhaps this information makes it easier to take a look to the OF.(I don't know what's your aggreement with austriamicrosystems about sharing this information)
thanks
Michael
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version