Rockbox mail archiveSubject: The iFP port (and its connection with the iPod port)
The iFP port (and its connection with the iPod port)
From: Tomasz Malesinski <tmal_at_mimuw.edu.pl>
Date: Sat, 7 Jan 2006 23:47:41 +0100
I have just sent this mail to the rockbox list by mistake.
Obviously, it should be sent here.
I have prepared a patch adding the iFP target. I would like the patch
to be reviewed and hopefully committed to CVS:
Compared to previous versions, with this patch some of the plugins
compile and work. Codecs also compile, but often cause the player to
crash. I haven't worked on this issue yet. Audio output is not
Buttons assignment in the user interface and plugins needs
correction. The UI simulator for the iFP could also be useful. If
someone would like to contribute to the port, but does not want to
deal with hardware details, I would suggest considering the above
So far I have found only 1 MB of RAM in the player. I have not
disassembled the player, so I don't know what chip is actually
inside. Because of small amount of RAM I disabled building the aac
codec for the iFP target.
Some of the changes may affect the iPod port. I added an instruction
disabling IRQs at the beginning of crt0.s and I also changed ending of
crt0.s in order not to enable IRQs. The iFP port requires that the
system_init is called before the interrupts may be enabled. I also
implemented the set_irq_level function for ARM in the system.h file.
This way the interrupts are enabled in the init function. Therefore I
would like the iPod port developers to test if the patch does not
break the iPod target.
I tried to compile the code without the -mlong-calls option in order
to get more compact code. The compilation failed because the long
calls are required in case of IRAM located functions. It should be
possible to fix this by adding __attribute((long_call))__ to those
functions, but it did not work. The functions were still called with
BL. Does anyone know what could be the reason?
-- Tomek MalesinskiReceived on 2006-01-07