Re: Improving simulator
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
Re: Improving simulator
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
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 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
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
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
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
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
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
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
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
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
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
