• Status Closed
  • Percent Complete
  • Task Type Patches
  • Category Operating System/Drivers
  • Assigned To No-one
  • Operating System All players
  • Severity Low
  • Priority Very Low
  • Reported Version
  • Due in Version Undecided
  • Due Date Undecided
  • Votes
  • Private
Attached to Project: Rockbox
Opened by dan_a - 2006-08-01

FS#5755 - Add the beginnings of coprocessor support on iPods

This 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.

(application/octet-stream)    cop.diff (9.8 KiB)
Closed by  dan_a
2007-03-04 21:32
Reason for closing:  Accepted
Additional comments about closing:   Warning: Undefined array key "typography" in /home/rockbox/flyspray/plugins/dokuwiki/inc/parserutils.php on line 371 Warning: Undefined array key "camelcase" in /home/rockbox/flyspray/plugins/dokuwiki/inc/parserutils.php on line 407

Committed to SVN r12601

dan_a commented on 2006-08-01 21:37

Ooops. This version should compile when USE_CPU is set.

(application/octet-stream)    cop.diff (9.8 KiB)

Nice work. A few minor comments:

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(0×80000000, 0×60007004);” could be replaced with “COP_CTL = 0×80000000;” 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…).

dan_a commented on 2006-08-02 12:01

I put in the #define because at the moment the coprocessor is doing nothing, so taking 1k from IRAM for the stack seemed a waste.

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.

dan_a commented on 2006-08-03 07:09

Updated taking Dave’s comments into account.
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.

(application/octet-stream)    cop.diff (6.3 KiB)
ryran commented on 2006-08-04 11:47

Ooooooooooooooooooooo this is exciting. I look forward to the day we can actually make the second cpu do something.

dan_a commented on 2006-08-10 14:10

cop.diff is now in CVS.

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.

dan_a commented on 2006-08-22 20:29

The threading changes are now in CVS.

dan_a commented on 2006-08-24 12:13

This patch runs a kernel on the second core (as well as a few other cleanups.) It needs testing on all generations of iPod.

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.

dan_a commented on 2006-08-24 16:17

Amiconn pointed out that we will need atomic mutex functions.
This patch could serve as a basis for these, but it fails to compile with error “internal_relocation (type: OFFSET_IMM) not fixed up”

I tried your kernel_on_cop.diff patch on my 5g, and Rockbox crashes with an immediate “*PANIC* Stkov” error…

What iPods has this been tested on?

dan_a commented on 2006-10-09 07:53

It has been tested successfully on a 3G, and unsuccessfully on an iPod photo.
It doesn’t apply to latest CVS, but I’m working on an updated version.

When you post something, I’ve got a Nano sitting around gathering dust. It’ll give me an excuse to set up the dev environment on my new laptop, since every other computer in my house died.

dan_a commented on 2006-10-10 23:15

Sync with current CVS; fix a possible bug in PP502X architectures.

dan_a commented on 2006-10-10 23:37

If this is applied on top of the previous patch, it will run the codec thread on the COP. This is just a proof-of-concept at present, as the processor cache needs to be disabled to make it work making performance far worse.

dan_a commented on 2006-10-12 12:10

Updated patch with some different PP502X tests. This includes running the codec thread on the COP and atomic mutexes (to prevent both cores trying to change the same thing at once)

Could you release a bootloader.bin please?
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.
* [all] Fehler 2

Compiling Rockbox (Buildprofile normal) builds OK

dan_a commented on 2006-10-13 09:16

bootloader.bin is attached.
If you are using CVS, try doing “cvs checkout bootloader” to get the bootloader source.

dan_a commented on 2006-10-13 13:21

The patch above does not apply correctly.
I will post a corrected version (confirmed working on iPod 5Gs - thanks, lostlogic!) this evening.

dan_a commented on 2006-10-13 17:49

This version is believed to work on all iPods. Wide testing would be appreciated.

I just tried this patch on my H10 (PP5020), but haven’t managed to get it working. I compiled a new bootloader and Rockbox firmware and put them on my device. Rockbox starts up fine, but when I go to play music, it stays stuck at 0 seconds.

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?

dan_a commented on 2006-10-14 10:52

That sounds very much like the coprocessor isn’t starting (or is hanging before init_threads() is called.) Having CPU frequency scaling disabled should cause no problems.

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.

dan_a commented on 2006-10-14 15:36

Confirmed working on an iPod Photo (thanks hcs!) but when linuxstb tried it on his 5G it did not work (with the same symptoms as Barry’s H10.)

I am trying to find out why this is.

Works on mini 2g, but when trying to load original firmware (by holding MENU) iPod just reboots back into bootloader.

dan_a commented on 2006-10-15 11:28

Tomasz: try saving your settings, restoring the original iPod firmware, and then installing the bootloader again.

Daniel: restored iPod to factory settings, installed bootloader again (from cvs), and still the same result. iPod makes strange sound and just reboots insted of booting original firmware.
The same happens with bootloader-mini2g.bin.
Without applying patch, bootloader can boot original apple firmware.

dan_a commented on 2006-10-23 15:32

It seems that with this patch threads that are supposed to be run on the coprocessor are still being run on the main core. I am still investigating to see if they are running on the COP at the same time.

Looks like it’s working on a Ipod Video (5g)
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

I’ve changed some code in powermgmt.c, diskcache.c and tagcache.c.
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.

Synced patch to CVS (kernel_on_cop_5.diff).

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.

Still doesn’t feel like it’s running on the COP to me. Just as much or more boost is needed to play audio. It’s also possible that we’re somehow lockstepping the cores, so that only one core is actually executing at a given time, which would give approximately the behavior that I’m seeing as well.

I did a battery test with this patch, and without, using identical CVS other than that, and from 90% to 10%, the battery lasted the exact same amount of time. I’m not sure how useful this information, but it suggests that either without the COP active, it’s still draining power, or it’s not actually active despite suggestion. Since the counter strongly suggests it is active if I understand what it’s supposed to be doing (haven’t actually looked at what it’s doing) then that’s probably an interesting bit of info.

I did a quick test to see if the codec thread is really running on the cop. I put a test for CURRENT_CORE==XXX just inside the while(1) in codec_thread(). With XXX=COP, the audio playback works as before. With XXX=CPU it doesn’t work and the pcm buffer never gets filled. I think that reasonably suggests that the codec thread is running on the COP as it should.

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.

Attached are my battery_bench results, trimmed to show the range from 90% to 10% (it actually spends a significant amount of time below 10%, so these don’t accurately reflect how long the full runtime is, but they should accurately show the difference in efficiency).

The first is without the coprocessor patch, the second is with kernel_on_cop_5.diff, and the third kernel_on_cop_6.diff

I’ve tried kernel_on_cop_6.diff with my in-progress mpegplayer developments, and when moving the video decoding to the COP, and using the main CPU to decode audio, I’m getting video playback speeds identical to when video was by itself on the main CPU, and perfect audio. So in the case of mpegplayer, there doesn’t seem any memory bottlenecks slowing things down.

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…

I’d like to add that I have experienced similar problems to Dave when using the kernel-on-cop patches. In the case of my H10, frequency scaling isn’t enabled by default. Using the kernel-on-cop patches, I was getting no main thread on the COP. I tracked the problem down to the call to ipod_set_cpu_frequency() in system_init(). I commented this out and got a main thread on the COP. I also tried replacing the ipod_set_cpu_frequency() function with a version based off cpufreq4.patch in  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.

Dave Chapman, I have tried the new PluginMpegplayer with sound and you recommend to apply the kernel_on_cop_6.diff patch if we are running an Ipod or iriver H10. I am running a ipod Photo (30GB) and after applying the patch Rockbox would just freeze.

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-224×128-354kbps.mpg

I also wanted to say Thank You and keep up the good work I appreciate it.

Tim, I have the same problem as you. I applied the kernel_on_cop_6.diff patch, now when I try to play a video, I can hear the audio, but just freezes at “buffering…“. I’m going the build the sources released today w/ the same patch and see if it works. If anyone has any more info about how you got the kernel_on_cop_6.diff patch to work, please inform. Thanks.

The kernel_on_cop_6.diff is not JUST for video support. If it doesn’t work with a specific part of Rockbox (in this case, mpegplayer) post what sort of iPod you have, and exactly what it does wrong, but this is not a discussion forum but rather patch feedback tracker.

dan_a commented on 2007-01-07 00:32

One user has reported that when running with kernel_on_cop_6 they are unable to go into disk mode by plugging in the USB cable (on a 5g). Can anyone reproduce this either on the 5g or on other models?

I’ve been watching this a while, and just jumped in to test it. I’m using an ipod 5g 30gb.

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 think perhaps there may be a problem with a scheduler. I don’t know the internal workings of rockbox well so I can’t say that it has such a function, though. It appears that even though the codec thread is on cpu1, threads on cpu0 are still affected, and may explain the behavior I described with menu scrolling. I’ve noticed while music is playing, sometimes other things show the same behavior. Sometimes I can get the menu up instantly, sometimes not. Sometimes I can descend further into the menu system instantly, sometimes not. It appears pretty random so I can’t nail it down to anything specific other than the fact I’m playing music. Please note that I’m referring to the system menu and not file browsing, so it should not be delays incurred by the disk.

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.

Just after that last update, I plugged my ipod into my computer via usb and it failed to go to disk mode. Music playback stopped, but it didn’t reboot. I unplugged it and music playback resumed on its own. I replugged it and it finally rebooted to disk mode. Once again, further testing needed to see relation with boosting.

I don’t think the usb connection detection problem is related to the cop patch. I can consistently reproduce the bug now and it appears to be related to the addition of mpegplayer. When on a fresh boot, without touching mpegplayer, it works properly. If I use mpegplayer, I have to reboot my ipod to be able to connect it to my computer. I haven’t been able to reproduce the exact problem I posted yesterday where I simply replugged it and it worked.

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.

I have just complied the source with the kernel_on_cop_6.diff patch. Adn When I try playing music in rockbox, there’s no music playing and the music progressbar didn’t even move. When I try playing MPEG video. It stuck at “Buffering…” but I can hear the sound of the video. Looks like it failed to create the thread on the COP. Then I try using senab’s COP build and having the same issue. Anything wrong?

dan_a commented on 2007-01-15 15:20

Tri: It sounds like the main thread is not running on the COP. Can you check this in the “Info→Debug→Debug OS Stacks” page?
What model of iPod are you using?

Tri: have you installed new bootloader ?

It worked the same for me when I booted patched roxkbox with unpatched bootloader, I’m on mini2g

I’m using an 2G ipod nano. And i boot to rockbox by IPL bootloader.

Tri: IPL bootloader causes this effect, build bootloader after applying the patch, and check if it works

I have try booting rockbox using ROLO bootloader, but i having the same issue again. Maybe the problem is in my ipod firmware. I’m using ipod firmware 1.3. And I have heard that this version of ipod firmware have some issue on rockbox.

I have uninstalled ipodlinux and create a fresh install of rockbox. It works now. Thanks.

Revision 12120 breaks this patch, requires updating

Synced to SVN.

Has anyone had any luck recording with this patch installed? Whenever I go to the recording screen, the player just freezes.

kernel_on_cop_7 shows a significant reduction in performance when installed. The UI is very slow. Still shows the threads as having been started on the other core though in the OS Stacks screen.

I can verify this on my 5.5G 30GB Video

also slow H10 2 threads on COP

same on the 4g, my recording screen also freezes with any of the kernel_on_cop patches

kernel_on_cop_7.diff seems to be giving me problems. If I try to boot, it shows the debug info until Sum. After that, it just resets the player. It’ll do that about 5 - 10 times, and then boot correctly. Anyone have any ideas?

You can try compiling a new bootloader with that code and loading it.

TrueJournals: I notice you said in IRC you used several patches. Did you test this with JUST the kernel_on_cop_7.diff? You should not report bugs on patches unless you’ve experienced the bug with ONLY that patch so that you can be 100% sure it causes it.

I tested it with this patch alone, and with a new bootloader compiled with it as well. Also, there are 4 others who are complaining of slow downs, so it would be safe to assume that cop 7 is causing the problem

Firstly: It is never safe to assume anything.

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 tried first with just the patch no changes to the bootloader.

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.

Those with H10’s who are experiencing problems with the kernel_on_cop_7 patch, it is likely for the same reason that previous kernel_on_cop patches caused problems. See my comment on 30th December for a description. In short, try commenting out ipod_set_cpu_frequency() in system_init() in system.c


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).

@Paul Louden
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.

Well… it turns out I was partly right. The culprit doesn’t seem to be this patch alone. It seems that this patch alone works, and the scrolling_margins patch alone works… but together, they cause the restarting problem. So, can anyone think of a way to fix this? Why hasn’t this occured in the past? Both the patches can be applied with no errors.

I tried the old kernel on COP 6 patch and hand edited in the rejects. I get the same slowness. It could be a change in the svn code.
I will try something a bit later to test

Its the playback.c modification in SVN number 12120

Hi Chris,

Are you sure it’s not the playback.c mod in revision 12125? The 12120 mod shouldn’t have any impact.

Sorry 12125 but I’m pretty damn sure its the playback.c modification, because I update SVN everyday, and after that day hell broke loose with cop

Soap commented on 2007-01-31 11:08

Steve / pondlife,

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.

I just reviewed 12120 and I’m still quite confident that it has no functional changes.

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?


Well, remember that the Coprocessor patch never gave the fully expected performance increase. The UI still slowed down during decoding even though it was offloaded to the COP which suggests that maybe not everything regarding COP support was entirely correct yet.

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 wonder if it’s a difference between 6 and 7 – 6 was made by me and included some hacking to make the codecs yield almost never does 7 include those changes?

I had a good look at 12120 and there’s only one change there that affects the code in any way (the two inline functions). Apparently reverting those changes still gave the sluggishness, so it seems likely that I missed something in creating v7. I made it by applying 6 on top of 12120 and manually merging the failed hunks. It’s very possible I missed something. Maybe someone should try syncing 6 again independently and see if they get the same result. It’s quite an easy sync, should only take a couple of minutes.

Are we sure it’s not related to the (good) fix in 12125. Ages ago I fixed a similar “buffer moving” problem in playback.c which resolved some crashes but then voice users started to report (on the ML) that list scrolling had slowed down big time. I just put it down to the then-new scheduler but somebody claimed they reverted my fix and it resulted in much improved speed. IRAM - related in some way perhaps?

I never revisited it as I personally prefer not to corrupt memory. ;-)

I’m testing 12120 line by line as suggested on the IRC, if its not that then we’ll just move to 12125. It has to be somewhere

I just made a patch based on kernel_on_cop_6, synced to SVN that seems to be working for me. I can play games and listen to music at the same time (something not possible with the COP). Anyway, can other people try this? Maybe this will solve the problems…

I’m going to test it out now to see if there is any improvment as on my H10 5Gb the kernel_on_cop_7 was causing reboots at the start and caused the movie player to not work correctly.

well I can’t say much about performence because I’ve only juse started patching so I have only tried the no.7 and it caused reboots at the start. That problem is now gone with this ver of the patch though. The performance did seem a bit sluggish though!

Soap commented on 2007-02-01 00:25

Target being iPod 5th gen: kernel_on_cop_8 installs cleanly on SVN 12167 and runs well - alleviating the problems I was experiencing with kernel_on_cop7. Main and Codec threads are verified running on the COP.

h10 20GB KoC8 working beatuifuly

Tested cop 8 on 5.5G iPod SVN 12168, seems to be working. Scrolling appears to be much slower than before (because I had William’s patch as per here:

i will test with the newest version from svn and COP8 tonight.
But this sounds good guys :)

Chris Wong:
My patch should also work with current svn and COP8. 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.

Running the CPU faster has even less to do with properly activating the coprocessor than it had to do with fixing the PP5020 crash.

Your patch patches system.c, so does cop 8, thus your patch gets rejected

dan_a commented on 2007-02-01 08:25

w1ll14m: Your frequency scaling patch is not relevant to getting the coprocessor working. This is a task for getting the coprocessor working under Rockbox - please lets keep it that way.

@Christ Wong: Are you saying that with KoCOP 8 WITH William’s patch is slower than normal? If so, please try KoCOP 8 WITHOUT William’s patch and see if that fixes the problem.

I’m saying that cop 8 on its own feels the same speed as without cop 8 (which is good because the ARM cores must be running at a lower frequency = longer battery life), but williams patch makes the scrolling faster because the CPU frequency is adjusted higher. If possible, boosting the CPU whilst scrolling would be really nice because it is very sluggish when going through a large playlist. On the 4G Grayscale and Color iPod I haven’t seen this problem.

Daniel Ankers:
Ok, i won’t say a word if it’s about anything else then COP ;)

dan_a commented on 2007-02-02 08:31

KoCOP8 confirmed working on greyscale 4G.

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.

Looking at a diff between 7 and 8, there are only two differences:

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?

With while (1) { yield(); } , the main thread will be constantly yielding - meaning that the COP kernel will be doing a lot more context switching than is necessary.

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?

I have KoC_8 running fine on a 5.5 30gb, the only problem I see is recording is now broken.I also have it running fine on a 4g gs, broken recording also.

seems to run fine on H10 20G i did notice a problem (might not be patch related I need to look futher) The boost count after abount an hour of playback was 400 + Like I said I need to do some more checking to see if it is related to this patch.

I wanted to report this again because Jason Lyons just mentioned it and I saw another person had a problem with it on This patch appears to break recording. If you go to the recording screen, then the player will just freeze up. I can confirm that it is THIS PATCH that is causing the problem because I have seen other reports of it.

dan_a does the cop patch help with the freezing on the 4G iPod?

Chris, I have run the cop patch from 100% battery all day long with no lockups til the battery died on a 4g grayscale.

dan_a what version of Loader2 are you using? Rockbox with cop 8 is working with Loader 2.5d6 on my 5.5G 30G iPod Video

dan_a commented on 2007-02-04 00:40

@decayed.cell: I get no lockups on the 4G greyscale with the KoCOP8 patch. I was not using the latest version of Loader2 which has support for the COP under Rockbox.

@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.

dan_a commented on 2007-02-04 01:56

We also need to make RoLo work correctly.

iPod mini G2: works with Loader 2.5d6

rockbox patched bootloader breaks booting into Apple firmware

in debug I see main and codec running on second core

found the problem with the high boost onunt on H10 and it was not related to this patch. I can confirm thin working (KoC8) on H10 20GBs

My tests

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

COP8 works fine on 2 ipod 5g’s
codec and main thread are confirmed running on cop

Possible Bug: 1G Nano + iPL Loader2.5d6, Disk mode not functioning in Rockbox, displays USB logo then fails to reboot into disk mode

Frankly, you should be testing with the Rockbox bootloader. If something doesn’t work while using the iPL loader, but works fine while running the Rockbox loader, then it qualifies as “Not our problem” but if it breaks while using the official bootloader, then it’s something that needs to be addressed.

I can verify that COP8 functions properly on my 1G Nano w/ the Rockbox bootloader. Disk mode functions properly as well.

I can confirm that COP8 works on an ipodmini1g.

I’ve been running kernel_on_cop_8 on my 4G (gray) for about a week now, using the iPL 2.5d6 (I can’t yet switch to the RB loader, since I have another user of my iPod who “requires” AppleOS.

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!

dan_a commented on 2007-02-17 17:14

Updated patch!
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.

The USB Bug is related to the new USB Detection routines I believe (the export files were changed etc.)

dan_a commented on 2007-02-17 22:54

Minor update: This should be more reliable when frequency scaling is disabled

This is probably a really stupid question and I’m sure the answer is yes, but just to be perfectly clear: Is cop10 also intended to work on targets where frequency scaling is still enabled?

Quote (from cop9): “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.)”

cop10 should be identical to cop9 on targets where frequency scalig is enabled. With frequency scaling disabled, cop9 still didn’t give a main thread on the COP on my H10, while cop10 does give a main thread.

Can anybody attach compiled .bin file with latest kernel_on_cop im gona try with Ipod nano 1G.I was trying apply patch but without luck.Thanks

Needs updating for current SVN

Updated for current SVN :p

More hunk errors. It appears to be due to the remote LCD driver changes in SVN.

Looks like they unified some code

Law commented on 2007-02-27 02:29

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.

Just to clarify, Paul Ninnis is referring to my (automated) daily build using the kernel_on_cop10.1.diff patch.

dan_a commented on 2007-02-27 08:17

Any improvement in stability you see while using this patch is purely coincidental.
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.

Are you sure? Given that my understanding is that no one understands what causes the crashes during frequency scaling, is it so unrealistic that using the coprocessor helps?

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)).

dan_a commented on 2007-02-27 08:36

Mike: What I meant was that this patch is not intended to help stability in any way. Using the coprocessor may well be helping, but that is a side-effect - not what I’m trying to achieve.

dan_a commented on 2007-02-27 23:16

Synced to SVN

dan_a commented on 2007-02-27 23:32

A working sync, to SVN r12512

Soap commented on 2007-03-03 22:22

Synced (I believe) to SVN r12574
Tested on a 5020 device.

Note, now apply -p0 instead of -p1

Hmm bit of a problem

patch: malformed patch at line 366: Index: firmware/export/pp5020.h

Fixed up the malformed bit

Updated for R12575

Oops slight spelling mistake

Synced to R12579


Available keyboard shortcuts


Task Details

Task Editing