dev builds
themes manual
device status forums
mailing lists
IRC bugs
dev guide

Rockbox mail archive

Subject: 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 <>
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

Page template was last modified "Tue Sep 7 00:00:02 2021" The Rockbox Crew -- Privacy Policy