Rockbox

  • Status Closed
  • Percent Complete
    100%
  • Task Type Patches
  • Category Operating System/Drivers
  • Assigned To No-one
  • Operating System All players
  • Severity Low
  • Priority Very Low
  • Reported Version Release 3.4
  • Due in Version Undecided
  • Due Date Undecided
  • Votes
  • Private
Attached to Project: Rockbox
Opened by kugel. - 2009-11-03
Last edited by kugel. - 2010-04-02

FS#10756 - Free unused init code

I’ve some code here that creates a dedicated section for init functions (i.e. those that are only called once and very early), inspired by the Linux Kernel.

There’s little point in keeping that code in otherwise usable RAM. That’s why my patch would copy move that code into a section that’s overwritten later.

For example, as my current patch works for e200v1: The code is in the same address area as bss. Before bss is zeroed, the init code is copied to the codec buffer. After calling main(), the init code is called from the codec buffer. The bss, following sections are moved over the init code, which effectively frees the code size init functions take. I use a very similar approach as iram code does.

On my e200, it yields ~6.7k. I would like to know if this kind of self-modifying code is considerable for SVN, or if it’s too dirty and/or dangerous. -6.7k isn’t *that* much.

Where the init code lands (codec or plugin buffer), and if the mechanism is really used, is entirely up to 1 ifdef in config.h and the target’s app.lds.

Closed by  kugel.
2010-04-02 17:10
Reason for closing:  Accepted
Additional comments about closing:  

Committed as of r25013.

I had the same idea some time ago, but instead of copying the init data at startup I tried putting all code at the end of the pcm buffer (before plugin start), so that it would get overwritten automatically on buffer fill.

However I failed doing this as I couldn't get the linker do this..

You need to copy, unless you want binaries that are almost as big as the RAM.

Hmm yes, too bad the main Rockbox binary doesn't use the ELF format or any other non-contiguous format (the Creative ZVM actually uses something similar to that, so in theory it could be done there).

Just spotted a left over addition in :

diff –git a/firmware/target/arm/sandisk/sansa-e200/lcd-e200.c b/firmware/target/arm/sandisk/sansa-e200/lcd-e200.c
index 03f6a1b..96d1326 100644
— a/firmware/target/arm/sandisk/sansa-e200/lcd-e200.c
+++ b/firmware/target/arm/sandisk/sansa-e200/lcd-e200.c
@@ -353,6 +353,7 @@ static void lcd_display_off(void)
}
#endif

+void lcd_init_device(void) INIT_ATTR;
void lcd_init_device(void)
{
/* All this is magic worked out by MrH */
@@ -435,6 +436,7 @@ void lcd_init_device(void)
#endif

   LCD_REG_6 |= 1; /* Start DMA */

+ _backlight_set_brightness(0);
}

#if defined(HAVE_LCD_ENABLE

And I think the description is wrong: the code isn't copied in bss section

Yea that was a left over from testing, I've spotted it already.

Where does the description indicate it's copied in the bss section?

"The code is in the same address area as bss. Before bss is zeroed, the init code is copied to the codec buffer."

What I see is that the copy in crt0.S is done just before bss zeroing, but I read the first sentence as "code is copied inside bss section"

Is there any reason for not committing this?

Upcoming release :) No need to risk things just now.

Ah /me always forgets those..

Do we wait until the 3.5 ?

I thought so, but it doesn't appear to happen :(

Loading...

Available keyboard shortcuts

Tasklist

Task Details

Task Editing