RE: DevCon 2007 - West Edition

[Austin Appel]

Reminders: If your status has changed from what you put on the wiki, please
update that.  I still have a bit of room in the suite...mail me if you are
reasonably sure you are going and would like to occupy a spot.  As said
before, it actually isn't pricey if done right and I am expecting it to be
somewhere in the range of $100-140 for both nights per person.

Also, if you are planning on staying after the conference, please mail me
*immediately* with the dates you would be able to stay as I need to decide
whether we will stay in a junior suite for the period, or not.

Lastly, if you have purchased flight tickets, please put down your arrival
time next to your name in the wiki.  If not, please edit the wiki when you
know this.

Re: Sansa (PP502x?) GPIO interrupts in rockbox software (aright, somebody see if they can catch something, please :)

[Michael Sevakis]

Some basic observations and they are confirmed correct after much toil and 
board spamming. :P

Simple to describe:
If I set bits 30 and 38, an endless stream of GPIO interrupts occurrs that I 
can't shut down by acknowledging any known bits. It makes absolutely no 
difference if any of the known GPIO ports has IRQs enabled. Is there some other 
GPIO port somewhere that's unmasked? Where?

Simple to describe:
If I set bit 30 alone, nothing. No GPIO IRQs occur at all or are pollable.

Very involved to describe:
If I set bit 38 alone, I can poll its status on timer interrupts but it's 
setting isn't reliable so can't be read reliably to check the GPIO ports. A few 
dozen to hundreds of timer tick interrupts will occur and the bit will be set 
in the status register and then disappear so long as I keep reenabling bit 38. 
If I don't keep resetting the bit, it's sort of a one shot with random firings 
here and there. Pushing a button or moving the scrollwheel runs it through the 
cycle again (with the port IRQs unmasked of course) but it's always read when 
the timer has fired. No matter about having the GPIOx_INT_EN set here but of 
course the button push won't cycle it again if they aren't so it's just once on 
the splash screen.

The OF sets bits 30 and 38 simultaneously and obviously has no flood 
difficulties...what's it doing? Is it checking anything when status bit 38 gets 
set besides GPIOx_INT_STAT?

The driver I made it seems is really just polling the GPIO IRQ status on timer 
interrupts and not truly receiving GPIO IRQs. I'm suprised it crips up the 
action so much.

Re: Towards restructured manual

[Martin Arver]

On 5/10/07, Jerry Van Baren wrote:

...or you have a "not supported" chapter for the units that don't
support a particular feature.  In the above example, for a unit
incapable of recording, Chapter 5 would become:

--
Chapter 5 Recording

Sorry, recording is not supported by the hardware.
--


Do you think we should use this approach for all features not
supported by a certain target? Like sw/hw-codec stuff, color display
possibilities or whatever. I mean, where should we draw the line on
what to include, and what to mark as 'Sorry X is not supported'? The
easiest is to follow the rockbox source code approach and use our own
latex ifdefs (\opt).

Re: Improving simulator

[pondlife]

> Having a separate "hosted" target is an idea that makes perfect
> sense, just not as a replacement for the simulator. There could
> even be 2: One SDL target, and one console target for the
> hardcore linux console fans. This way we could provide a nice
> media player for linux, and it would also allow making rockbox
> run on e.g. Windows Mobile devices.

I agree with *this* approach.

-- 
Steve B

Re: Towards restructured manual

[Jerry Van Baren]

Martin Arver wrote:

I like that way too. We could have separate chapters for Radio,
Recording etc. The only drawback is the fact that the manual chapter
numbers will then vary between the targets, and as users tend to name
only the section number instead of its name this might cause some
misunderstandings. Not sure if that is too much a concern though.


I do though like the idea that you get a specific chapter for
recording if your player supports that feature. People, and we tend to
refer to numbering, but the manual being in draft/developing status
atm those numbers can and will change anytime.
My wish is that we could focus towards a future release where the
manual stays the way it is and the recording chapter is e.g. chapter 5
for targets with that feature, and for the others chapter 5 is the
plugin chapter (e.g.). This is not a big problem in my humble opinion.


...or you have a "not supported" chapter for the units that don't 
support a particular feature.  In the above example, for a unit 
incapable of recording, Chapter 5 would become:


--
Chapter 5 Recording

Sorry, recording is not supported by the hardware.
--

This way the numbering matches.  The downside is that someone will get 
excited briefly because they think that the mentioned feature (e.g. 
recording) is possible on their hardware, but their irrational 
exuberance[1] will be tempered quickly.


gvb

[1] 

Re: Towards restructured manual

[Martin Arver]

How about putting an a "This target does not have the capabilities to
" so we always have a chapter for everything and the numbers
stay constant...?


Nah, should we really? We do provide target specific manuals and i
think those should only include what the target supports without the
need to write "this feature is not supported by this target".

Martin

Re: Towards restructured manual

[Martin Arver]

I like that way too. We could have separate chapters for Radio,
Recording etc. The only drawback is the fact that the manual chapter
numbers will then vary between the targets, and as users tend to name
only the section number instead of its name this might cause some
misunderstandings. Not sure if that is too much a concern though.


I do though like the idea that you get a specific chapter for
recording if your player supports that feature. People, and we tend to
refer to numbering, but the manual being in draft/developing status
atm those numbers can and will change anytime.
My wish is that we could focus towards a future release where the
manual stays the way it is and the recording chapter is e.g. chapter 5
for targets with that feature, and for the others chapter 5 is the
plugin chapter (e.g.). This is not a big problem in my humble opinion.

Re: Improving simulator

[Jens Arnold]

On 10.05.2007, Christian Gmeiner wrote:

> 2007/5/10, Dave Chapman <[EMAIL PROTECTED]>:
>> Christian Gmeiner wrote:
>> The big plus point is that we dont need to care about the
>> simulator with #ifdef's anymore as the simulator is a normal
>> target.

>> I don't see how that will happen - won't it just mean
>> replacing "#ifdef
>> SIMULATOR" with "#ifdef SDL_TARGET" ?

> No you are wrong.. we will use the target tree feature:
> firmware/target/sdl/*

> Here we implement, for instance, a lcd driver based on sdl,
> audio driver based on sdl,...

I think this idea misses the whole purpose of the simulator: The
simulator is intended to write and debug high level code *for
specific targets*. Making it a separate target doesn't make
sense in respect to that.

Having a separate "hosted" target is an idea that makes perfect
sense, just not as a replacement for the simulator. There could
even be 2: One SDL target, and one console target for the
hardcore linux console fans. This way we could provide a nice
media player for linux, and it would also allow making rockbox
run on e.g. Windows Mobile devices.



Regards, Jens

Re: Sansa (PP502x?) GPIO interrupts in rockbox software

[Michael Sevakis]

Some of what I said  is definitely wrong. I _can_ see the bits set if I set 
during an interrupt if I keep them set and I can stop IRQs anytime it seems. 
These GPIO interrupts seem to be polled interrupts and the GPIO IRQ is actually 
a signal to poll for which devices need service. My problem is: I cannot seem 
to filter for CPU_HI_INT_STAT & GPIO_MASK to reject the need to check 
GPIOx_INT_STAT constantly. I can poll the devices during a timer interrupt and 
that's what was happening for but the GPIO happening 
reliably..unless...interestingly, if I keep polling the devices on _every_ 
timer interrupt, we'll also get more GPIO IRQs so actually polling seems to be 
important for keeping the main GPIO IRQ active but it appears _not_ during the 
same interrupt as the inital request to poll.

What you're observing makes almost perfect sense to me now. What I'd like to 
know is when it actually looks at the ports after it gets the GPIO IRQ and 
other details you can get.

Re: Improving simulator

[Jonathan Gordon]

On 10/05/07, Dominik Riebeling <[EMAIL PROTECTED]> wrote:

On 5/10/07, Christian Gmeiner <[EMAIL PROTECTED]> wrote:
> Have a look at this:
>
> [EMAIL PROTECTED] ~/rockbox $ find apps/ | xargs grep 'SIMULATOR' | wc -l
> 694
> [EMAIL PROTECTED] ~/rockbox $ find firmware/ | xargs grep 'SIMULATOR' | wc -l
> 640

Just thought of the plugins ... look at this, this is quite interesting too:
$ grep -R SIMULATOR apps/plugins/ | wc -l
229

(leaving around 400 lines in apps/ after Dave's last cleanup)

 - Dominik


hmm... I did the same thing and gt different numbers, /me's bach +
grep-ing obviously sux

Re: Towards restructured manual

[Jonathan Gordon]

I like that way too. We could have separate chapters for Radio,
Recording etc. The only drawback is the fact that the manual chapter
numbers will then vary between the targets, and as users tend to name
only the section number instead of its name this might cause some
misunderstandings. Not sure if that is too much a concern though.


How about putting an a "This target does not have the capabilities to
" so we always have a chapter for everything and the numbers
stay constant...?

Re: Improving simulator

[Dominik Riebeling]

On 5/10/07, Dominik Riebeling <[EMAIL PROTECTED]> wrote:

Just thought of the plugins ... look at this, this is quite interesting too:
$ grep -R SIMULATOR apps/plugins/ | wc -l
229


Hehe, seems we fell into the same trap: find (and grep -R too) also
finds the hidden special files put there by svn. So, repeating the
counting but leaving out all files that include .svn in the path, I
get this values with current svn:

$ find firmware/ | grep -v .svn | xargs grep SIMULATOR | wc -l
342
$ find apps/ | grep -v .svn | xargs grep SIMULATOR | wc -l
365
$ find apps/plugins/ | grep -v .svn | xargs grep SIMULATOR | wc -l
125

which makes the values somewhat nicer. Not that it changes the problem
itself, but IMO this isn't that much a problem with that values
(grepping for #ifdef in apps/ finds nearly 4000 lines ;-)

- Dominik

Re: Improving simulator

[Dominik Riebeling]

On 5/10/07, Christian Gmeiner <[EMAIL PROTECTED]> wrote:

Have a look at this:

[EMAIL PROTECTED] ~/rockbox $ find apps/ | xargs grep 'SIMULATOR' | wc -l
694
[EMAIL PROTECTED] ~/rockbox $ find firmware/ | xargs grep 'SIMULATOR' | wc -l
640


Just thought of the plugins ... look at this, this is quite interesting too:
$ grep -R SIMULATOR apps/plugins/ | wc -l
229

(leaving around 400 lines in apps/ after Dave's last cleanup)

- Dominik

Re: Towards restructured manual

[Dominik Riebeling]

It's already been a while, but I always wanted to reply on this topic, so ...

On 5/2/07, Martin Arver <[EMAIL PROTECTED]> wrote:

I think we can simplify certain parts of the manual, and move stuff around.
For one, i think the "root menu" could be described as early as in the
quick start chapter with pointers to in-depth descriptions of the
different parts (Files, Database etc).


I agree, but we shouldn't call it "root" menu at any stage, as it has
been agreed to consider it as the new main menu. A real root menu
would behave a bit different ...


So, a little feedback and ideas would be great at this stage. Like,
what to do with Radio, Recording etc.


I like that way too. We could have separate chapters for Radio,
Recording etc. The only drawback is the fact that the manual chapter
numbers will then vary between the targets, and as users tend to name
only the section number instead of its name this might cause some
misunderstandings. Not sure if that is too much a concern though.


- Dominik

Re: Improving simulator

[Dominik Riebeling]

On 5/10/07, Dave Chapman <[EMAIL PROTECTED]> wrote:

That's what I'm saying - people have been mistakenly adding #ifdef
SIMULATOR when it's not needed, or adding it as a quick fix instead of
implemnting things for the simulator.

I can't see how this will change with a target-tree approach - either
you need to implement things in SDL, or the sim will continue to not
behave the same as the real device.


There is also another concern that pops in my head: the more-advanced
users (i.e. those who want to use the sim, but are not too much into
the Rockbox code itself) might think it is just another port of
Rockbox, namely to the PC. This might cause quite some confusion.

I don't think it's worth the effort, instead, providing more stubs
would be easier and faster reaching almost the same goal IMO. You'll
need to implement the stuff for the PC anyway (as you otherwise would
need to #if defined(CPU_SDL) or something similar, which doesn't make
a difference at all), and when moving you also need to verify all #if
defined(SIMULATOR) too.

- Dominik

Re: Improving simulator

[Christian Gmeiner]

2007/5/10, Jonathan Gordon <[EMAIL PROTECTED]>:

as has been said, the vast majority of #ifdef SIMULATOR is in apps/ so
moving to a target-tree sort of system wouldnt make sense...


Have a look at this:

[EMAIL PROTECTED] ~/rockbox $ find apps/ | xargs grep 'SIMULATOR' | wc -l
694
[EMAIL PROTECTED] ~/rockbox $ find firmware/ | xargs grep 'SIMULATOR' | wc -l
640

Re: Improving simulator

[Jonathan Gordon]

as has been said, the vast majority of #ifdef SIMULATOR is in apps/ so
moving to a target-tree sort of system wouldnt make sense...
What might be beneficial is adding more stubs to
uisimulator/common/stubs.c but really, is there any real point?
Surely spending time in the code for real targets would be more
beneficial? (unless someone wants to try a sdl port for non-pc
target?)

Re: Improving simulator

[Christian Gmeiner]

2007/5/10, RaeNye <[EMAIL PROTECTED]>:

I agree with the general idea, but I see a problem with allowing the
simulator to be configured for different platforms.
We need to configure lcd size & depth, RTC availability, available buttons
and keymaps, remote lcd and buttons if applicable, etc.
These are not questions I'd like to answer while running tools/configure
(maybe the lcd size is ok, but buttons?) so there has to be a way to make it
read some code off the relevant target tree.


To create the config-sdl, we can use the informations from the choosen
target conf-xxx.
So we can have a stub config-sdl, which we fill with target specific
informations.

config-x5
|
\/
ready to use config-sdl -> compile rockbox
/\
|
config-sdl stub

Re: Improving simulator

[Dave Chapman]

Christian Gmeiner wrote:
> 2007/5/10, Dave Chapman <[EMAIL PROTECTED]>:
>> I don't see how that will happen - won't it just mean replacing "#ifdef
>> SIMULATOR" with "#ifdef SDL_TARGET" ?
> 
> 
> No you are wrong.. we will use the target tree feature:
> firmware/target/sdl/*

How would adding a new target help with all the use of #ifdef SIMULATOR
in apps/ and the non target-tree parts of firmware/ ?

It's this high-level (i.e. not target-tree) code which has the most
instances of #ifdef SIMULATOR.

>>
>> Looking at the current code, there seem to be a lot of #ifdef SIMULATOR
>> checks which are not needed - e.g. lines of the form:
>>
>> #if defined(CPU_COLDFIRE) && !defined(SIMULATOR)
>>
>> can just be changed to:
>>
>> #ifdef CPU_COLDFIRE
>>
>> - the CONFIG_CPU macro in the config files aren't defined for the
>> simulator.
>>
>> Another problem is simply hardware features of targets which are not
>> implemented in the sim - mainly the MAS on Archos devices, radio,
>> recording, plus various other things like HAVE_PWM_BACKLIGHT_FADING.
>> How would your proposal deal with these?
> 
> 
> I dont want to write an emulator, I want to integrate the simulator
> better into the current source! These are two _very_ different things.

I didn't mention anything about writing an emulator.  I'm talking about
the fact that there are many features which work on the target but not
in SDL, which is the reason for many of the #ifdefs you want to remove.

In order to get rid of those #ifdefs, you would either need to implement
the features for your SDL target (something you could just do now), or
remove the relevant HAVE_ macro from the config file and hence remove
all trace of the feature from the UI (again, something you can do now).

> We can run now rockbox on our pc with sdl.. we will use sdl to play
> sound and so on. But you have now the same core (threading,..) as we
> would compile rockbox for a target, which can help debugging.

The kernel and threading isn't part of target-tree, so your suggestion
isn't a pre-requisite for making the sim use the same core kernel as the
targets.

I agree that it would be great if the simulator used the same kernel as
the targets, but the problem is how to implement the hardware-specific
parts of the kernel in a portable way using SDL.  A problem that still
exists if the SDL code is in target-tree.

>> I'm not convinced that a radical change in architecture is needed - the
>> time might be better spent just implementing more features in the
>> current sim, and ensuring #ifdef SIMULATOR is only being used when it
>> absolutely has to be.
> 
> 
> Believe me that nobody wants to check, if this ifdef is okay or not...
> its much easier when there are none or a very small amout of these
> #ifdef SIMULATOR.

That's what I'm saying - people have been mistakenly adding #ifdef
SIMULATOR when it's not needed, or adding it as a quick fix instead of
implemnting things for the simulator.

I can't see how this will change with a target-tree approach - either
you need to implement things in SDL, or the sim will continue to not
behave the same as the real device.

I'm not saying that moving the SDL code into target-tree is a bad idea,
just that I don't think it will make the huge difference you think it will.

Dave.

RE: Improving simulator

[RaeNye]

I agree with the general idea, but I see a problem with allowing the
simulator to be configured for different platforms.
We need to configure lcd size & depth, RTC availability, available buttons
and keymaps, remote lcd and buttons if applicable, etc.
These are not questions I'd like to answer while running tools/configure
(maybe the lcd size is ok, but buttons?) so there has to be a way to make it
read some code off the relevant target tree.

Re: Improving simulator

[Linus Nielsen Feltzing]

Christian Gmeiner wrote:

Hmm... good question ;) If I recheck it in my head then it will work
without the bootloader. We
create a normal executable and run it.


Sounds good.

All in all, I think this sounds like a good idea.

Unfortunately, the target tree concept only applies to the "firmware" 
part of Rockbox, while many SIMULATOR dependencies are in the "apps" 
part, the codecs and plugins for example.


It will certainly clean up some of the mess but not all, I'm afraid.

Linus

Re: Improving simulator

[Christian Gmeiner]

2007/5/10, Linus Nielsen Feltzing <[EMAIL PROTECTED]>:

Christian Gmeiner wrote:
> To run the new created rockbox.x86 we need a special boot loader,
> which loads compiled code form x86 and executes it.

Why would we need that?


Hmm... good question ;) If I recheck it in my head then it will work
without the bootloader. We
create a normal executable and run it.

Re: Improving simulator

[Linus Nielsen Feltzing]

Christian Gmeiner wrote:

To run the new created rockbox.x86 we need a special boot loader,
which loads compiled code form x86 and executes it.


Why would we need that?

And how would this work with gcc? Wouldn't this cause some extra 
problems loading the correct symbol tables etc?


Linus

Re: Improving simulator

[Christian Gmeiner]

2007/5/10, Dave Chapman <[EMAIL PROTECTED]>:

Christian Gmeiner wrote:
> The big plus point is that we dont need to care about the simulator
> with #ifdef's anymore as the simulator is a normal target.

I don't see how that will happen - won't it just mean replacing "#ifdef
SIMULATOR" with "#ifdef SDL_TARGET" ?


No you are wrong.. we will use the target tree feature:
firmware/target/sdl/*

Here we implement, for instance, a lcd driver based on sdl, audio
driver based on sdl,...



Looking at the current code, there seem to be a lot of #ifdef SIMULATOR
checks which are not needed - e.g. lines of the form:

#if defined(CPU_COLDFIRE) && !defined(SIMULATOR)

can just be changed to:

#ifdef CPU_COLDFIRE

- the CONFIG_CPU macro in the config files aren't defined for the simulator.

Another problem is simply hardware features of targets which are not
implemented in the sim - mainly the MAS on Archos devices, radio,
recording, plus various other things like HAVE_PWM_BACKLIGHT_FADING.
How would your proposal deal with these?


I dont want to write an emulator, I want to integrate the simulator
better into the current source! These are two _very_ different things.
So... whren we build a simulator for target X5, we will get a sdl
based executable (in combination with the bootloader), which has the
same size of lcd as x5, has the same buttons as x5, has recording if
supported - like our current uisimulator.

We can run now rockbox on our pc with sdl.. we will use sdl to play
sound and so on. But you have now the same core (threading,..) as we
would compile rockbox for a target, which can help debugging.



I'm not convinced that a radical change in architecture is needed - the
time might be better spent just implementing more features in the
current sim, and ensuring #ifdef SIMULATOR is only being used when it
absolutely has to be.


Believe me that nobody wants to check, if this ifdef is okay or not...
its much easier when there are none or a very small amout of these
#ifdef SIMULATOR.

Christian

Re: Improving simulator

[Dave Chapman]

Christian Gmeiner wrote:
> The big plus point is that we dont need to care about the simulator
> with #ifdef's anymore as the simulator is a normal target.

I don't see how that will happen - won't it just mean replacing "#ifdef
SIMULATOR" with "#ifdef SDL_TARGET" ?

Looking at the current code, there seem to be a lot of #ifdef SIMULATOR
checks which are not needed - e.g. lines of the form:

#if defined(CPU_COLDFIRE) && !defined(SIMULATOR)

can just be changed to:

#ifdef CPU_COLDFIRE

- the CONFIG_CPU macro in the config files aren't defined for the simulator.

Another problem is simply hardware features of targets which are not
implemented in the sim - mainly the MAS on Archos devices, radio,
recording, plus various other things like HAVE_PWM_BACKLIGHT_FADING.
How would your proposal deal with these?

I'm not convinced that a radical change in architecture is needed - the
time might be better spent just implementing more features in the
current sim, and ensuring #ifdef SIMULATOR is only being used when it
absolutely has to be.

Dave.

Re: Improving simulator

[Christian Gmeiner]

2007/5/10, Linus Nielsen Feltzing <[EMAIL PROTECTED]>:

Christian Gmeiner wrote:
> But I am not a build system guru.. so somebody need to help out, if my
> idea of a simulator is wanted and accepted by the community and the
> developers.

One major hassle with simulator builds are the plugins, and I don't see
how a separate x86 target could help that. By the way, X86 is a bad
target name, since the sim can run on Mac OSX with PowerPC, can't it?


The name is not good.. so rename it to target sdl

Re: Improving simulator

[Linus Nielsen Feltzing]

Christian Gmeiner wrote:

But I am not a build system guru.. so somebody need to help out, if my
idea of a simulator is wanted and accepted by the community and the
developers.


One major hassle with simulator builds are the plugins, and I don't see 
how a separate x86 target could help that. By the way, X86 is a bad 
target name, since the sim can run on Mac OSX with PowerPC, can't it?


Linus

Re: Improving simulator

[Christian Gmeiner]

Hi Steve,

2007/5/10, pondlife <[EMAIL PROTECTED]>:

Hi Christian,

I agree with the principle.  As well as device support, the simulator
currently uses some other separate kernel code (all the multi-threading for
example).  I would particularly hope that such a simulator could be used to
debug some of the more subtle issues (race conditions etc.) which it
currently often fails to reproduce at all.

Such a simulator would still need to offer an emulation of different
targets' hardware - in particular display capabilities (sizes, colours, and
the Archos Player's charcell display) and buttons.


For this step we need to modify tools/configure.
* select wanted target
* select simulator
* buildsystem needs now to generate a config-x86 on-the-fly based on
config-xxx of selected target.

But I am not a build system guru.. so somebody need to help out, if my
idea of a simulator is wanted and accepted by the community and the
developers.

Greets,
Christian

Re: Improving simulator

[pondlife]

Hi Christian,

I agree with the principle.  As well as device support, the simulator
currently uses some other separate kernel code (all the multi-threading for
example).  I would particularly hope that such a simulator could be used to
debug some of the more subtle issues (race conditions etc.) which it
currently often fails to reproduce at all.

Such a simulator would still need to offer an emulation of different
targets' hardware - in particular display capabilities (sizes, colours, and
the Archos Player's charcell display) and buttons.

-- 
Steve B

Improving simulator

[Christian Gmeiner]

Hi all.

I know the sources of rockbox for a long time and I think its time for
a revolution :) Maybe you all know the #ifdef SIMULATOR stuff all over
the source... and we could get rid of them with some work.
My idea is to create a new target called x86 where we write
audio/lcd/ata/threading drivers based on sdl and normal *nix.
If a user/developer selects now in tools/configure his player and then
Simulator the build system should generate a
firmware/export/config-x86 based on the selected target (screen size,
recording, remote control, ...) and then should start compiling a
rockbox.x86, plugins and other stuff.

To run the new created rockbox.x86 we need a special boot loader,
which loads compiled code form x86 and executes it.

something like
# bootloader rockbox.x86 
Starting RockBox simulator for target XY...

The big plus point is that we dont need to care about the simulator
with #ifdef's anymore as the simulator is a normal target.

What do you think about my idea?
Thanks,
austriancoder