Rockbox mail archiveSubject: Re: The iFP port (and its connection with the iPod port)
Re: The iFP port (and its connection with the iPod port)
From: Dave Chapman <dave_at_dchapman.com>
Date: Tue, 10 Jan 2006 01:41:22 +0000
Tomasz Malesinski wrote:
> 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:
I've briefly looked at it, and in my opinion, I think we should commit
it to CVS.
There are a few places where your choices of #ifdef could be different -
e.g. using CPU_ARM instead of CONFIG_CPU==PP5020 || CONFIG_CPU==PNX0101
You could also define IRIVER_IFP7XX_SERIES, and use that where
appropriate instead of CONFIG_CPU.
But these are minor points - it's in a much better state than my first
ipod commit was.
> 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've tested it on my iPod color and it doesn't appear to have any bad
> 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?
I fought with this for a while when first trying to compile Rockbox for
the ipod. The current solution of using -mlong-calls was the only one I
could get to work. Like you, I tried adding the long_call attribute,
but gcc appeared to ignore it.
But if you do manage to find a solution, please let us know.
Received on 2006-01-10