This is the bug/patch tracker for Rockbox. Click here for more information.
Quick links: Bugs · Patches · Rockbox frontpage
FS#5755 - Add the beginnings of coprocessor support on iPods
|
DetailsThis patch adds the most basic support for the second processor on PortalPlayer-based machines (i.e. iPods.)
It does not run any code on the second processor, merely adds in the framework to allow it. It changes code in the bootloader, and the updated bootloader will not run old versions of Rockbox correctly. The current bootloader will run this version of Rockbox, but the coprocessor code will never be reached. It also adds an extra #define to firmware/export/config-ipod*.h: USE_COP This must be defined to reserve some stack for the coprocessor. 
cop.diff
(9.8 KiB)
apps/main.c | 19 ++++++++++ bootloader/ipod.c | 4 +- firmware/app.lds | 11 +++++ firmware/crt0.S | 67 +++++++++++++++++++++++++++++++++--- firmware/export/config-ipod3g.h | 4 ++ firmware/export/config-ipod4g.h | 4 ++ firmware/export/config-ipodcolor.h | 4 ++ firmware/export/config-ipodmini.h | 4 ++ firmware/export/config-ipodmini2g.h | 4 ++ firmware/export/config-ipodnano.h | 4 ++ firmware/export/config-ipodvideo.h | 4 ++ 11 files changed, 124 insertions(+), 5 deletions(-) |
This task depends upon
Closed by Daniel Ankers (dan_a)
Sunday, 04 March 2007, 22:32 GMT+2
Reason for closing: Accepted
Additional comments about closing: Committed to SVN r12601
Sunday, 04 March 2007, 22:32 GMT+2
Reason for closing: Accepted
Additional comments about closing: Committed to SVN r12601
I'm not sure if there's a need for a USE_COP #define - I think it's pretty certain that all PortalPlayer devices will use the COP for something, so I would just enable your code for all PP targets.
Also, try and avoid using outl as much as possible in Rockbox, and use the #defines in pp5002.h/pp5020.h instead. e.g. the statement "outl(0x80000000, 0x60007004);" could be replaced with "COP_CTL = 0x80000000;" This makes the code easier to read, and in some cases removes the need #ifdefs to distinguish between different PP architectures.
Finally, in bootloader/ipod.c, I think you can just delete the code you've surrounded with #if 0 - we've always got CVS as a history if we need to go back to old code (and the comment at the end of load_rockbox() needs updating...).
I'll get rid of any "outl"s that I can and add any appropriate defines into the pp50xx.h files, and have an updated patch on here later.
If there are no other comments, I'll update this once more to use the new CPU_PP define and then commit it to CVS this evening.
I'm not going to have much time to work on this over the next few weeks, so attached is a dump of the current work-in-progress. Chances are it won't compile on anything other than a 3g iPod, and it is nowhere near in its final form (a lot of the work is not in the appropriate file, a lot is failed experiments, a lot of comments need correcting).
The work is currently at a stage where as long as the processor cache and frequency scaling are turned off then it is possible to run a thread on the second core (this work attached starts the codec thread on the second core).
The next steps in getting this into Rockbox are:
1. Separate out the threading API changes, check that they work across all builds and get them into CVS.
2. Separate out the changes required to run a kernel on the second core, including identifing and solving the problem with frequency scaling (if HAVE_ADJUSTABLE_CPU_FREQ is set, Rockbox will not boot.) Get these changes into CVS.
3. Identify any potential cache concurrency issues within Rockbox preventing dual core working. This will probably include changing the queueing code.
4. Update any documentation as appropriate and start a "using the second core" Wiki page.
Once these things have been done, it should be relatively easy for other developers to write code which runs across both cores, and I will have a look at getting the codec thread running on the second core and the impact of this on battery life, playback skips, etc.
Once this has been applied, developers can choose to run a thread on the second core. The API to do this will be improved a little before committing, but for now a thread can be started on the second core by doing:
threadnum = create_thread_on_core(COP, my_thread, my_stack, sizeof(my_stack), "my thread")
Remove the thread by doing
remove_thread_on_core(COP, threadnum)
The core that the thread is running on will show in the OS Stacks debug menu.
This patch could serve as a basis for these, but it fails to compile with error "internal_relocation (type: OFFSET_IMM) not fixed up"
It doesn't apply to latest CVS, but I'm working on an updated version.
I always get stuck like this:
...
CC target/arm/ipod/3g/backlight-3g.c
CC target/arm/ipod/3g/button-3g.c
CC target/arm/ipod/power-ipod.c
CC target/arm/ipod/usb-ipod.c
AR+RANLIB /home/kripton/rockbox/rockbox/build/librockbox.a
make: *** /home/kripton/rockbox/rockbox/bootloader: No such file or directory. Stop.
make: *** [all] Fehler 2
Compiling Rockbox (Buildprofile normal) builds OK
If you are using CVS, try doing "cvs checkout bootloader" to get the bootloader source.
I will post a corrected version (confirmed working on iPod 5Gs - thanks, lostlogic!) this evening.
Looking at the audio debug menu, the codec buffer gets filled up but the pcm buffer remains empty the whole time.
The OS Stacks debug menu shows all threads apart from the codec thread running on core 0. There is only one main thread and the codec thread is using 0%.
Finally, the system_reboot() function seems to no longer work with these patches applied.
That was about all I could figure out until I thought maybe it was because CPU frequency scaling is disabled on the H10. I tried enabling frequency scaling and things got worse rather than better. Having it enabled in the bootloader caused Rockbox not to start at all. It got as far as showing the logo, then I could hear the hdd get powered off and spin down. There was nothing further updated on the LCD, it just locked up there. Commenting out the code in ide_power_enable() in firmware/target/arm/iriver/h10/power-h10.c and rebuilding the bootloader allowed Rockbox to boot the same as before frequency scaling was enabled.
I'm very confused by all this behaviour. Any thoughts?
Looking through the code, I can't see anything which should stop it working on the H10 and not on the iPods.
The change to the iPod bootloader was merely to make main() return after loading Rockbox, which the H10 bootloader in CVS does.
There would seem to be some small differences with the PP5020 and the PP5021 used by the 5G - perhaps one of these differences is causing the problem. If someone with a 4G, Photo or G1 Mini iPod could test this, it would tell us more.
I am trying to find out why this is.
The same happens with bootloader-mini2g.bin.
Without applying patch, bootloader can boot original apple firmware.
Had some problems, i've never patched rockbox before :) but i've had succes.
Core and Stack usage:
(0) *R 4 main: 72%
(0) S 4 scroll: 17%
(0) B 6 usb: 5%
(0) B 6 backlight: 16%
(0) *R 6 power: 32%
(0) T 4 audio: 55%
(0) S 6 ata: 21%
(0) B 8 dircache: 5%
(0) T 8 tagcache: 8%
(0) T 8 playlist cachectrl: 9%
(1) S 4 main: 11%
(1) *R 4 codec: 88% --> :)
My conclusion is that with this patch my playback buffer is better, and menu's are less interupting audio,
Before this patch when i go wild scrolling, the audio stops (ipod has to rebuffer the song).
With the patch it takes longer, and my menu's are a little faster.
Keep up the good work, this patch Really ROCKS
Now the OS Threads debug shows that Power, diskcache and tagcache are moved to the COP core.
but my rockbox has become a little unstable, but that's probably because this is the first time i've edited a sourcecode for rockbox :)
ow maybe it is because thos threads have to run on the main CPU.
Well i just have to wait till the COP process is a little more advanced is the process.
This now seems to work with my H10, possibly due to the recent crt0 changes. I'm now experiencing none of the problems I previously reported.
I think I have verified that threads created on the COP now run only on the COP. Apply the attached cop_counter.diff on top of the kernel_on_cop_5.diff to test. It runs a thread on the COP which just increments a counter. The debug I/O ports screen shows the counter increasing. Changing the test for "if(CURRENT_CORE == COP)" to "if(CURRENT_CORE == CPU)" makes the counter no longer increment.
That still leaves the question of why we don't see any performance benefit. The two possibilities I see are either that we're somehow lockstepping the cores as lostlogic said, or that the codec thread doesn't use much processing power. I think the codec thread should be fairly CPU intensive, so i suspect that the problem is with code not running in parallel on both cores (lockstepping). Any suggestions for how to test for this? Or is there a third possibility that I haven't considered?
Ok, going along with Barry's patch, I've created a works-for-me updated patch that 'proves' that the codec thread is running on the COP by not yielding in the codec thread. Performance seems a bit better to me, but someone will need to back me up. In order to keep the COP from going to sleep forever waiting for current_tick to change, I also moved current_tick to IRAM.
Performance isn't a bunch better, which leads me to believe that Jens' comments in IRC today about memory performance possibly being the bottleneck might be spot on.
The first is without the coprocessor patch, the second is with kernel_on_cop_5.diff, and the third kernel_on_cop_6.diff
So at least the kernel-on-cop part of the patch seems to be fine.
I should add that when using it on my ipod Photo (PP5020-based), I got immediate freezes when starting Rockbox. Disabling CPU frequency scaling immediately solved that problem. However, hcs reported in IRC that he tried the v6 patch on his Photo and it worked fine with CPU scaling enabled...
FS#6095. This also gave me a main thread running on the cop. Finally, enabling frequency scaling also gave me a main thread (in this case ipod_set_cpu_frequency() is never used).So it looks like there are some problems with setting the frequency while the COP is running. cpufreq4.patch does some checks on the COP whenever changing frequency, so that could be a good place to start looking.
Do you have a patch or instructions for what you did to Disable CPU frequency scaling on your iPod Photo?
What other patches do you have applied?
What theme do you have running, and does that change the MpegPlayer's frame-rate?
Can you post your iPod build?
I tried removing #define HAVE_ADJUSTIBLE_CPU_FREQ from config-ipodcolor.h and it let me continue into Rockbox however the Mpegplayer would just have sound and saying buffering (I never seen a video clip just sound) unlike before applying the kernel_on_cop_6.diff patch the sound was played before the video and sounded like the rate was correct maybe even fast however the frame-rate was very slow and well behind the sound. I was getting very slow frame-rates with the example video nothing near your reported 25fps with elephantsdream-q6-224x128-354kbps.mpg
I also wanted to say Thank You and keep up the good work I appreciate it.
I've noticed that list scrolling is tied to cpu speed. When cpu is unboosted, scrolling is a bit slow. When boosted (playing music), it's a bit faster and smoother. This behavior has changed with this patch. While boosted, it is fast, but erratic. It appears to pause periodically, then speed up again.
As for the disk mode on usb cable connect on the 5g, I can confirm that this works, but there was a noticeable delay detecting the usb connection.
I have not experienced any crashes or lockups yet, but I'm not done testing!
The only testing I've done so far is by playing ogg music. I will do more testing when I can. I will have multiple firmwares ready to go on my ipod so I can do some testing away from my computer.
I will have to do further testing to see if there is any relation with boosting since that appears to be an issue that Dan wants tested against.
I can't reproduce this bug outside of the cop patch...mpegplayer refuses to work without it as it fails to create the video thread.
What model of iPod are you using?
It worked the same for me when I booted patched roxkbox with unpatched bootloader, I'm on mini2g
As I said, I have performance degredation, but that's different from failing to boot. I'm one of the people who reported the slowdown. I want to know if the failed boots happens with JUST the patch.
I booted fine but did notice slowness. updated the bootloader, same slowness. Turned dircache on and off again, booting happened faster. But navagation was still slower then normal.
Tried with cpu boosting enabled but the same slowness persists. When I look in debug info -> OS Stacks, I see two main threads, one on 1 and one on 0 both taking up a heftey amount of %. I will look futher into the ipod_set_cpu_frequency() method when I get home from work tonight. I would like to mention that kernel_on_cop6 did not suffer from this issue (boosting is turned on).
Sorry, I'll try later today making a build with just the kernel_on_cop_7.diff patch and see if that does anything. If not, I'll add my patches one by one to see which one is the culprit.
I will try something a bit later to test
Are you sure it's not the playback.c mod in revision 12125? The 12120 mod shouldn't have any impact.
Current SVN runs fine.
Current SVN +KoCOP#7 runs very poorly, like molasses in January.
Current SVN with 12120 removed and KoCOP#6 applied = all runs fine.
Is it possible that the error is in how we're applying the COP patch on top of 12120? Anyone else want to review the changes in 12120 and see if I changed something functional and didn't notice?
:-\\
Then when you consider that any change to playback.c shouldn't cause COP support to slow down the UI unless there's something wrong with the COP support itself, maybe somehow the reorganization just brought odd things to light in regards to how the newest KoC7 patch?
I'm just sayin', instead of blaming the "almost certainly not changing function" SVN change, maybe KoC needs to be examined further, since it wasn't working entirely right anyway. Just because 12120 brought it to light, doesn't mean there's anything *wrong* with 12120. ('course, just to be fair, nothing proves that there's nothing wrong with it either.)
I never revisited it as I personally prefer not to corrupt memory. ;-)
But this sounds good guys :)
Chris Wong:
My patch should also work with current svn and COP8.
http://rockbox.schoorl.nu/cpu_freq_60-90-v1.patch
if it's necessary i will resync the patch to current SVN but as far as i know it should cleanly apply to current SVN.
Ok, i won't say a word if it's about anything else then COP ;)
The current official bootloader works for COP builds - you do not need to use the ones in this thread. Loader2 (from the iPodLinux project) however does not.
1. 7 puts voice_thread_start in IRAM, 8 doesn't. I don't think this would make a huge difference. Maybe someone more familiar with it would know.
2. 8 uses sleep(HZ) in the loop in cop_main() while 7 uses yield(); It seems like this is probably the reason for the slowness experienced in 7. What exactly is the difference between the two? Would it be expected for yield() to give such slowness?
The sleep(HZ) means that the main thread will only be woken up once a second. But maybe there should be a better way for a thread to say "sleep forever". Or maybe the main thread could commit suicide itself after it's initialised the kernel?
@everybody: I think this is close to being ready for SVN.
The status on the various targets is:
G3 iPod: Not working - main thread is created but audio does not play
G4 G/S iPod: Working
G4 Colour iPod: Not tested
G5 iPod: Working
G5.5 iPod: Working
iPod mini G1: Not tested
iPod mini G2: Not tested
iPod nano G1: Not tested
iriver H10: Working
Sandisk Sansa: Working if frequency scaling is supported
The known bugs which have not been resolved yet are:
Boost ratio increasing (can't reproduce here)
Recording not working (I suspect this is to do with cache issues)
Does not work if frequency scaling is disabled
Work to do:
Test killing the main thread on the COP after running the kernel
Implement a runtime test to see if the COP is available - this will make builds with incompatible bootloaders work.
rockbox patched bootloader breaks booting into Apple firmware
in debug I see main and codec running on second core
G4 G/S iPod: Working with iPL Loader 2.5d6, reboot when Loading Original Firmware with Rockbox Bootloader
G4 Colour iPod: Working with iPL Loader 2.5d6 + Rockbox Bootloader
G5 iPod: Working with iPL Loader 2.5d6 + Rockbox Loader
G5.5 iPod: Working with iPL Loader 2.5d6 + Rockbox Bootloader
iPod mini G2: Working with iPL Loader 2.5d6, reboot when Loading Original Firmware with Rockbox Bootloader
iPod nano G1: Working with iPL Loader 2.5d6 + Rockbox Bootloader
codec and main thread are confirmed running on cop
Stability is greatly improved vs. no patch, but not as solid as removing scaling. I've seen (in a total of about about 15 hours of testing (2 * 45min-1hour daily) two cases of freezing on the WPS and two occurances of something very weird; the apple logo appears for a second, then the display goes blank. A reboot is required.
On the bright side, no data aborts!
This fixes the recording bug. My 4G greyscale boots and plays music if compiled with no frequency scaling support, so that bug might be fixed too (it works correctly with frequency scaling support too.)
The API for creating threads changes with this patch, to:
struct thread_entry* create_thread(void (*function)(void), void* stack, int stack_size,
const char *name IF_PRIO(, int priority)
IF_COP(, unsigned int core, bool fallback))
Where 'core' is the core the thread is to be created on - either CPU or COP, and 'fallback' is whether to create the thread on the other core if it can't be created on the requested core. create_thread_on_core is no longer used. This reduces binary size on single core targets by around 100 bytes.
There are a number of other code cleanups too.
There is a bug that if you boot with the USB inserted then Rockbox hangs.
Apply this patch using "patch -p1 < kernel_on_cop9.diff" from your rockbox directory.
I still get lockups during playback on a 4G Color Photo 60Gig iPod with the COP10 build (25 Feb 07). It seems to also run slower with this build than with the standard build (apparent when scrolling and changing menus, very apparent on the game "bubbles").
Using the noscaling build still works fine without lockups during playback.
I was not able to see any decrease in speed on my G4 greyscale, but it would be appreciated if other people could check this on their players.
Attached is the latest version of the patch - this adds support for gracefully failing if an old bootloader is being used. I intend this to be the last patch and hope to put this into SVN shortly.
With a regular build, my 4G crashes within minutes. With cop10 (haven't tried 11 yet), I can usually get at least 3 hours playback without a lockup (and usually a full battery worth (4-5 hours)).
Tested on a 5020 device.
Note, now apply -p0 instead of -p1
patch: **** malformed patch at line 366: Index: firmware/export/pp5020.h