Daniel Stenberg | 3 Aug 18:38 2006

Re: dan_a: apps main.c,1.178,1.179

On Thu, 3 Aug 2006, cvs <at> labb.contactor.se wrote:

> Initial work for coprocessor support on iPods.  FS#5755

...

> +/* This is the entry point for the coprocessor
> +   Anyone not running an upgraded bootloader will never reach this point,
> +   so it should not be assumed that the coprocessor be usable even on
> +   platforms which support it.

And for the devices using PP chips without being ipods?

--

-- 
  Daniel Stenberg -- http://www.rockbox.org/ -- http://daniel.haxx.se/

Daniel Ankers | 3 Aug 18:57 2006
Picon

Re: dan_a: apps main.c,1.178,1.179

> On Thu, 3 Aug 2006, cvs <at> labb.contactor.se wrote:
>
>> Initial work for coprocessor support on iPods.  FS#5755
>
> ...
>
>> +/* This is the entry point for the coprocessor
>> +   Anyone not running an upgraded bootloader will never reach this
>> point,
>> +   so it should not be assumed that the coprocessor be usable even on
>> +   platforms which support it.
>
> And for the devices using PP chips without being ipods?

This will work for all PP-based devices which Rockbox supports.

Daniel Stenberg | 3 Aug 22:06 2006

SanDisk Sansa e200 owners, join in!

Hey

Just wanted to mention that we now have a bootloader embryo for SanDisk Sansa 
e200 players committed to CVS, so now is a perfect moment for lurking Sansa 
owners to jump on the train.

We know how to run code on target (and how to safely revert back to a 
functional original firmware) but we don't know much about to use LCD, 
read/write flash, read buttons or similar...

I'll try to keep info and details about the reverse engineering progress here:

 	http://daniel.haxx.se/sansa/e200.html

Occational talks about it is also kept here:

 	http://forums.rockbox.org/index.php?topic=3225.0

--

-- 
  Daniel Stenberg -- http://www.rockbox.org/ -- http://daniel.haxx.se/

Liberman Shachar (Lamed | 4 Aug 18:19 2006
Picon

better non-language support, one button hold for horizontal scrolling patches.

hey.

The first patch I want to discusse is 
http://www.rockbox.org/tracker/task/5587,

There are more then a few languages that use special characters that aren't 
present in rockbox's internal font.
(ie bulgarian, chinese-trad, greek, japanese, hebrew, just a few that I've 
picked up.)
knowing supporting two unicode fonts simply isn't going to happend, I see 
one good way around this:
simply stating off when a language string is going to be used in the rockbox 
internal font, and using a different language string there.
that way, the translator would choose a different translation (could be the 
original english word) on those internal font occurrance:

LANG_REPEAT is used under (general settings > playback > repeat) with 
unicode support,
and LANG_SYSFONT_REPEAT is used under the quickscreen menus.

as a future reference:
A. a note for the translators: take care of the new LANG_SYSFONT_ that are 
added at the end of your language file (with the same translation as the 
original LANG_ string:) if they are not displayed correctly, (around 
quickscreens, the equalizer screen and recording,) submit a patch that 
solves the issue.
B. a note for the developers: Please keep using LANG_SYSFONT_ strings when 
using the internal font.

______________________________________________________________________
(Continue reading)

tracker | 5 Aug 00:00 2006

Open bugs in Rockbox

Flyspray contains 104 open bugs:

2 years 109 days old: Corrupt files using time split feature
6 comments, 0 files: http://www.rockbox.org/tracker/2147

317 days old: Rewinding at end of song confuses playback 
6 comments, 0 files: http://www.rockbox.org/tracker/2687

161 days old: iPod going into USB mode when using the wall charger.
4 comments, 0 files: http://www.rockbox.org/tracker/4724

160 days old: text viewer setting saving not working on ipods
2 comments, 0 files: http://www.rockbox.org/tracker/4729

157 days old: USB Bootloader Mode not working properly
14 comments, 0 files: http://www.rockbox.org/tracker/4753

154 days old: Random resets when playing while plugged in (USB)
1 comments, 0 files: http://www.rockbox.org/tracker/4762

151 days old: Rockbox doesn\'t shut down gracefully on low battery.
7 comments, 0 files: http://www.rockbox.org/tracker/4786

150 days old: \"Basic battery monitoring\" not working on ipod nano.
6 comments, 1 files: http://www.rockbox.org/tracker/4795

148 days old: status-bar enabled, problem with screen refresh
3 comments, 0 files: http://www.rockbox.org/tracker/4808

137 days old: Can\'t navigate menus using the H300 remote joystik.
(Continue reading)

tracker | 5 Aug 00:00 2006

Open patches in Rockbox

Flyspray contains 270 open patches:

3 years 154 days old: Edit ID3 Tags
20 comments, 9 files: http://www.rockbox.org/tracker/1008

3 years 152 days old: Add current playing track to 1 of 10 files
11 comments, 3 files: http://www.rockbox.org/tracker/1028

2 years 350 days old: Sleep mode after n tracks (req# 674890)
2 comments, 1 files: http://www.rockbox.org/tracker/1642

2 years 349 days old: Extended volume fade options
10 comments, 2 files: http://www.rockbox.org/tracker/1645

2 years 345 days old: Enhanced menus + MDB patch (for recorder)
2 comments, 1 files: http://www.rockbox.org/tracker/1656

2 years 331 days old: beep when battery low
8 comments, 1 files: http://www.rockbox.org/tracker/1682

2 years 308 days old: Increase/decrease volume from .cfg file
0 comments, 1 files: http://www.rockbox.org/tracker/1720

2 years 308 days old: Increase/decrease volume from cfg file
0 comments, 1 files: http://www.rockbox.org/tracker/1721

2 years 278 days old: Change Volume while recording
0 comments, 1 files: http://www.rockbox.org/tracker/1773

2 years 226 days old: Fade out until sleep mode
(Continue reading)

Daniel Ankers | 7 Aug 11:18 2006
Picon

Proposed changes to threading API

Greetings all,
I have been looking at using both cores on PortalPlayer based devices
(iPod, Sansa E200, iRiver H10.)
I think that supporting this is going to require changes to the threading
API so that threads can be run on both cores.

I propose:
1. Changing the variables in thread.c such as num_threads to be arrays
(e.g. num_threads[NUM_CPUS])  I don't think that any of these variables
get referenced from outside thread.c apart from by the debugging menus.

2. Adding functions to create/remove a thread from a specific core:
int create_thread_on_core(unsigned int core, void (*function)(void),
                  void* stack, int stack_size, const char *name)
void remove_thread_from_core(unsigned int core, int threadnum)

3. Changing the existing create/remove_thread to be:
int create_thread(void (*function)(void), void* stack, int stack_size,
                  const char *name)
{
    return create_thread_on_core(CURRENT_CORE, function, stack, stack_size,
                  name);
}

void remove_thread(int threadnum)
{
    remove_thread_from_core(CURRENT_CORE, threadnum);
}

CURRENT_CORE would be the core that the thread is being created from.
(Continue reading)

Jonathan Gordon | 7 Aug 11:45 2006
Picon

Re: Proposed changes to threading API

is there any reason why the thread has to stay on one core?
And on the topic of threads, what about changing to prioritising
threads? especially the audio thread.
And lastly, put in a schedular so threads dont have to explicitly
yield (maybe this will stop the problem where you have to reset if the
ui thread crashes but audio/backlight still work?)

On 07/08/06, Daniel Ankers <dan-rockbox <at> weirdo.org.uk> wrote:
> Greetings all,
> I have been looking at using both cores on PortalPlayer based devices
> (iPod, Sansa E200, iRiver H10.)
> I think that supporting this is going to require changes to the threading
> API so that threads can be run on both cores.
>
> I propose:
> 1. Changing the variables in thread.c such as num_threads to be arrays
> (e.g. num_threads[NUM_CPUS])  I don't think that any of these variables
> get referenced from outside thread.c apart from by the debugging menus.
>
> 2. Adding functions to create/remove a thread from a specific core:
> int create_thread_on_core(unsigned int core, void (*function)(void),
>                   void* stack, int stack_size, const char *name)
> void remove_thread_from_core(unsigned int core, int threadnum)
>
> 3. Changing the existing create/remove_thread to be:
> int create_thread(void (*function)(void), void* stack, int stack_size,
>                   const char *name)
> {
>     return create_thread_on_core(CURRENT_CORE, function, stack, stack_size,
>                   name);
(Continue reading)

Daniel Stenberg | 7 Aug 12:34 2006

Re: Proposed changes to threading API

On Mon, 7 Aug 2006, Jonathan Gordon wrote:

(This has nothing to do with Dan's original questions. I thought his 
suggestions looked fine!)

> is there any reason why the thread has to stay on one core?

Simplicity? Why would a thread "move" between threads?

> And on the topic of threads, what about changing to prioritising
> threads? especially the audio thread.

Whoa! Why would we want that? And if so, how would it work?

> And lastly, put in a schedular so threads dont have to explicitly yield 
> (maybe this will stop the problem where you have to reset if the ui thread 
> crashes but audio/backlight still work?)

Gosh. Abandoning the cooperating multi-tasking of current Rockbox will open 
all gates to hell and lead to no good. We'll need a bazillion locks, mutexes 
and similar things and then still have to debug for thread-related problems 
and dead-locks for many months/years ahead.

I'm strongly in favour of keeping our current simple threading system. KISS.

--

-- 
  Daniel Stenberg -- http://www.rockbox.org/ -- http://daniel.haxx.se/

Jonathan Gordon | 7 Aug 12:40 2006
Picon

Re: Proposed changes to threading API

/me backs away... quickly...

On 07/08/06, Daniel Stenberg <daniel <at> rockbox.org> wrote:
> On Mon, 7 Aug 2006, Jonathan Gordon wrote:
>
> (This has nothing to do with Dan's original questions. I thought his
> suggestions looked fine!)
>
> > is there any reason why the thread has to stay on one core?
>
> Simplicity? Why would a thread "move" between cores?
couldnt you have a problem where one core could be asleep and the
other core be thrashing away  <at>  100% ?
>
> > And on the topic of threads, what about changing to prioritising
> > threads? especially the audio thread.
>
> Whoa! Why would we want that? And if so, how would it work?
>
> > And lastly, put in a schedular so threads dont have to explicitly yield
> > (maybe this will stop the problem where you have to reset if the ui thread
> > crashes but audio/backlight still work?)
>
> Gosh. Abandoning the cooperating multi-tasking of current Rockbox will open
> all gates to hell and lead to no good. We'll need a bazillion locks, mutexes
> and similar things and then still have to debug for thread-related problems
> and dead-locks for many months/years ahead.
>
> I'm strongly in favour of keeping our current simple threading system. KISS.
>
(Continue reading)


Gmane