Rockbox

  • Status Closed
  • Percent Complete
    100%
  • Task Type Patches
  • Category Bootloader
  • Assigned To No-one
  • Operating System iAudio X5
  • Severity Low
  • Priority Very Low
  • Reported Version
  • Due in Version Undecided
  • Due Date Undecided
  • Votes
  • Private
Attached to Project: Rockbox
Opened by RaeNye - 2006-05-03
Last edited by amiconn - 2011-06-19

FS#5289 - Dual Boot for X5

Press REC to boot original firmware.

Note: as the OF checks for a long ON press, be sure to keep ON pressed for 1 seconds after pressing REC.

To compile:
have x5-patch-original-fw.c in tools, gcc it
have original x5-fw.bin in your build-x5-bootloader dir
enter build-x5-bootloader dir and make
../tools/x5-patch-original-fw bootloader/bootloader.bin x5-fw-new.bin

The patch is OF version independent.
Comments are welcome.

Closed by  amiconn
2011-06-19 17:25
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

r30018 implements dual boot support based on the latest version of this patch..

Project Manager

Cool! I’ll certainly test this soonish!

Project Manager

Way to go!

I have one comment: I don’t really like that it is tied to a specific OF version…

Which version of the OF is this tied to?

Project Manager

Ugggg… I do not like this approach. Assuming fixed addresses in the cowon bootloader will strike back and hit is in the face sooner or later.

It’s not tied to a *changeable* OF version.
It relies on the preloader, which stays in flash addresses 0×0 to 0×10000.

There’s no dependance on the OF itself (2.10-k, 2.10-e, 2.11beta, …)

Project Manager

But still, are you sure this is the same vectors for X5V too and that there’s no newer/older models with different code?

I believe that no other versions of the preloader exist (they didn’t even recompile it w/o debug information!),
but I changed the code to use RB’s pcf50606 functions. I’m staying with the original patch, though :)

Note 1: it compiles, but I didn’t test it on my X5. Maybe the bcc.s is wrong.
Note 2: I added an automatic bypass for RTC alarm wakeup, since the OF supports it. It should be removed once RB features an alarm clock.

R.

Project Manager

Ah, this approach looks much better to me!

Project Manager

except that the second patch makes my X5 start in “all black” mode that I can’t escape. I can see the LED go red and I believe there’s a disk spinup but then nothing until I use my paperclip.

I tried the first patch then and it worked.

Two requests about this (except the bug). I’m aware this might be a bit premature but I thought I’d let you know anyway:

1. please provide diffs with -u

2. I would appreciate if you could move this fw-patch code to the mkboot source code, as that’s already used for the h100 and h300 players to “patch in” bootloaders. Then I’d also like to see you use all three file names given as command line arguments and not assume a particular file in “current directory”.

The reason for it is probably the horrible i2c-generic.
I tried to fix the 2nd patch by including I2C routines from the preloader and now it just doesn’t work (i.e., boots RB).
Maybe you could help me find the bug (I left the debugging screens in this patch).
All I know is that for some unknown reason it wouldn’t set RxAk after writing the device byte (0×10) to MBDR2.

About mkboot, I renamed x5-patch-original-firmware.c to mkboot-x5.c (no common structure is shared between iriver’s mkboot and mkboot-x5, so they shouldn’t reside in the same file) and added it to tools/{Makefile,configure}. I also added the OF as a command line parameter.

everything except crt0.S works flawlessly, please commit these to the cvs and crt0.S will be added when it’s bug-free.

P.S.
I’m still sure that the first patch is much safer.

Project Manager

1. Why is i2c-generic horrible for this use case? And even it it was, I don’t see how you fix it by avoiding it.

2. I would still prefer using mkboot since it doesn’t add another tool and the use case is the _exact_ same as the existing mkboot tool, only another platform. And mkboot already takes an argument specifying target.

3. How can the first patch be “much safer”? Please explain.

1. I need pcf50606 read/write functions, and I can either use the preloader’s, rockbox’s or my own.
i2c-generic introduces global variables, which I prefer not to have before rockbox is initialized. You’ve seen it crashing the device for no good reason.

2. mkboot (which is actually mkboot-iriver) has a very different structure, and you can’t easily isolate the platform dependent code. Your best shot would be to rename main() there to main_iriver() and have mkboot-x5’s main() renamed to main_iaudio().
Do you really think it’s the right thing to do?

3. The first patch wraps tested and valid code with small asm patches. The last patch is 10 times the size of it, and probably contains 10 times the bugs (it obviously contains at least one whereas the first patch works).
I have no more leads in the debugging of it, so unless you have any idea, I’m pretty much stuck there.
(read: After spending a few hours in debugging it, I’ve concluded that I prefer to add support for more hardware over fixing a non-existant bug).

Project Manager

1. Ok, so your program bugs and possibly the i2c generic can be improved. I still think fixing the problems is the right way rather than to adding the very obscure and hard-to-track dependency on a fixed address in the cowon firmware. I rather depende on our code.

2. I do. The situation we have is an ever increasing amount of platforms we support and without carefully doing things like this we will also add a new tool for every new target, for no good reason IMHO. Yes, the x5 approach is totally different and by all means keep the code in a separate .c file if you think that is the correct way. Users that have BOTH irivers and x5 will indeed benefit from using the same tool (with only a modified option) and manual writers will cheer having to document the single approch and so on. And again, when we add support for more platforms we extend the tool to support them too…

3. You actually consider the Rockbox code to be “much” more unstable than relying on an absolute address to the cowon code?

Yes, if we *REALLY* cannot make it work the “right” way (according to me) I could be persuaded to apply the one I disagree with. Of course we can also improve it to right in the future.

We might as well move this discussion to the rockbox-dev list for more opinions…

1+3.
I make no claims about the stability of Rockbox code in general;
I know that I prefer using Cowon’s code – which I have inspected thoroughly – than using /my/ obviously buggy implementation. Indeed, I tried to call RB’s well-tested PCF50606 code, alas it fails in this case.

From my point of view, Cowon’s functions are API calls into a shared library loaded before my code.
Would you be less reluctant to use fixed addresses if before using Cowon’s code I’ll verify its checksum?

2.
Let’s say I add an option to choose whether RB or the OF is booted by default (many users have asked for it).
Now you require all mkboot-<platform> to support it?
Should I refrain from adding this functionality just because mkboot-iriver is broken without it?

In fact, I don’t want even to *compile* mkboot-iriver if my build is any non-iriver platform.
It’s a useless dependency in my makefile.

See fsck for a good example (IMHO) for how it should be done.
I suggest mkboot to be a shell script calling the right mkboot-<platform>.

BTW,
Could you think of a non-volatile place to store a single bit other than flash/HDD ?
(for saving the ‘which firmware should boot by default’ variable)

Project Manager

Yes, I wouldn’t mind seeing this taken to the dev list.

Yes if the firmware code would somehow be checked in a rudimentary way that it is likely to be the one we expect, at least we can provide a way to signal if the startup fails due to this. Like with some special led-flashing combo or something.

I can’t stop you from doing whatever you want, but users all over always whined about the bootloader order and so far we haven’t made any bootloader boot in the reversed order mainly because A) it is rockbox bootloader it loads Rockbox B) if you really really want the OF primarily then you should probably not have the bootloader in the first place and C) we really should work and focus on making Rockbox stable and good enough so that user’s won’t feel the need for a reversed boot preference.

Ok, so if we consider fsck a “good” way of solving the problem then how’s your approach to making the mkboot use that approach? Of course you don’t get tools built that you won’t need, but according to me the mkboot is the tool that would be used for firmware bootloader patching and then you need to compile it…

Project Manager

Besides, if the Rockbox pcf50606 driver doesn’t work for the bootloader, then I suggest we fix that bug instead of using the cowon functions.

Luckz commented on 2006-05-08 11:11

Wouldn’t it in any case be easier to have the whole thing always boot from Rockbox? Waiting for that (three seconds?) and pressing REC and so on a bit (two seconds?) really isn’t that horrible, while, on the other side, it sounds like a total nightmare to make it NOT automatically load the OF anymore once you start making it do that.

(the discussion continues in rockbox-dev list)

A new overhauled version!

1. Major change: no more holding the REC button to boot OF.
As the OF requires a long ON press anyway, I thought it’d be easier (and less-handed) to differentiate between firmwares by the length of the ON press: short press=RB, long press=OF.

2. It should support remote ON button as well; I have none to check with, so tell me if it doesn’t.

3. Is 25ms sleep enough for everybody? I’m able to choose which firmware boots without errors. Anyone can’t?

4. I know I’m still calling sleep() from the preloader; I’ll soon implement it and get rid of the dependency.

R.

Fixed charger/usb issue.
To boot RB from charge/usb screen, hold the ON button for about half a second (the time it takes me to quickly say “One, two”).

(mkboot-x5.c didn’t change, grab it if you don’t have it)

Note: my independent sleep() function is written but not working.
Find the bug to make it preloader-independent.

Use the patch from May 12nd, the 17th is flawed;
however it’s quite possible to boot RB from charge/usb screen by holding the ON button for about half a second (the time it takes me to quickly say “One, two”).

MT69 commented on 2006-07-28 22:22

Hi I’m kinda new to rockbox. I was wondering how to apply the dual-x5 patch from May 12 2006 so I can load both RB and OF. Thanks.

moixa commented on 2006-08-03 15:51

I quickly merged the mkboot-x5 functionality into the existing mkboot. See attached patch.
It’s not very nice coding as I did not remove the duplicated code for reading the
various files or checking signatures for example. But this is what it could look
like having a single utility.

What I actually want is the dual boot functionality in CVS.. I am currently running
it without any notable hitch so far. Any timeline on this? Unmet requirements I could help with?

Thanks for the effort, but I made a merged version several weeks ago
(see http://forums.rockbox.org/index.php?topic=3766.msg41304#msg41304).

The problem is that currently the dual bootloader code relies on fixed addresses in the OF preloader.
Read the entire thread above for details (check the rockbox-dev archives as well).

It is a little not in a theme. A switcher between Cowon and Rockbox.

Make Directories and Copy Files:

\FIRMWARE

COWON
  x5_fw.bin       /* This is Cowon Firmware */
ROCKBOX
  x5_fw.bin     /* This is Rockbox ware */

For loading Cowon firmware copy file \FIRMWARE\COWON\x5_fw.bin to folder \FIRMWARE and turn power off.
(~ 2 minutes).

For loading Rockbock ware copy file \FIRMWARE\ROCKBOX\x5_fw.bin to folder \FIRMWARE and turn power off.
(Some seconds)

Not so is fast, but it is absolutely reliable

Excuse me, spaces was eaten.
Once more.

\FIRMWARE\COWON\x5_fw.bin
\FIRMWARE\ROCKBOX\x5_fw.bin

This rather old suggestion is bad for several reasons:
1. You need the AC adapter and a power outlet to perform the switch. You’re helpless without them, e.g., on the road.
2. You need to reprogram the flash for every switch. The chance of failure during that is higher than of Cowon changing the preloader ever (they didn’t even strip debug code from it :).
3. The whole process is slow: you need to boot the DAP in the current firmware, copy a file, shutdown, connect AC adapter, wait for upgrade, reboot. At least a few minutes.

Also, it has nothing to do with the patch itself or its development.

Here is the updated patch for both iaudio x5 & m5. Thanks Rani for help!

I changed the patch to not rely on any address in the original firmware. It now performs the delay using a busy wait, so we only rely on the CPU speed. Furthermore, I increased the delay to 3 seconds since the original delay was way too short for me. This doesn’t mean that you now have to wait 3 seconds before Rockbox starts, the delay loop is terminated as soon as the ON button is released.

Comments? Does anybody see a reason why this patch shouldn’t be applied?

Disclaimer: I haven’t tested this patch with the latest Rockbox so far, but I’ve been using it for about 9 months with the then-current Rockbox without any problem and it applied cleanly to the latest source, so I don’t expect problems.

I also thought about busy-waiting, and while it’s less elegant than a proper sleep() method, it’s definitely better than OF dependency rendering dual-boot unofficial.

The break-as-soon-as-no-button-is-pressed is nice as well, but I prefer a shorter delay anyway (maybe 2 seconds?) to avoid interfering with the 10-seconds-POWER-press-forces-shutdown mechanism.

Issues/ideas to consider:
- detect remote HOLD button and avoid remote boot when remote HOLD is active.
- pass RTC alarm to RB (instead of OF) once RB supports it.
- “cheat” the OF by marking that an RTC alarm has occured, in order to relieve the user from holding POWER for 5+ seconds.

Bottom line: gets my vote.

Project Manager

I like it. My only problem is that the merged mkboot.c by Rani Hod is nowhere to be found, since it only existed as an attachment in a forum thread. I’ll try to get this committed once the mkboot.c patch is attached here.

One more minor concern: I kind of liked that the installation process is so simple if you don’t want dual boot. I’d like an option to compile a standalone bootloader like before.

There’s a merged mkboot attached to this Flyspray entry above, but I think I had a problem with it and went back to the standalone mkboot-x5. But I’ll have another look at it. Or in case Rani is still reading here: Could you attach your version as well?

The single-boot option should be trivial to do, will have a look at it this evening (I guess a compile-time option is OK, with dual boot being the default?).

Project Manager

Compile-time option is perfect.

Let’s hope that Rani can attach his mkboot.c here.

Sure, here it is (sorry for not gzip’ing, it’s short).

Notes:
1. Update bsig[] in lines 190-191 for the correct start of x5-bootloader.bin ;
2. This should work for X5V as well; the only difference is that the firmware signature there is “COWON_X5V_FW” instead of “COWON_X5_FW”. This could be verified in mkboot as well.
3. The whole RTC alarm check (tst.b 0×3000000) is somewhat fishy, since people report in  FS#7814  that it works with dual boot nevertheless. Maybe research this some more.

   mkboot.c (7.7 KiB)

OK, here we go. Sorry for the delay, real life…

Attached is an updated and hopefully final version of the iAudio dual boot patch. As discussed, dual-boot functionality can be disabled now by #defining IAUDIO_NO_DUALBOOT when compiling.

The patch also contains a slightly updated version of Rani’s mkboot.c. I fixed a few broken perror() calls and added comments explaining the magic constants used, so that I still know what we’re doing when I look at this again in a few months :-) I noticed that in the meantime, mkmkboot.c and mktccboot.c have appeared in SVN. Somebody might want to merge them into mkboot.c as well…

Hopefully, this is now suitable for SVN.

There’s one remaining question: What do we do about the documentation and the pre-built bootloaders at http://download.rockbox.org/bootloader/iaudio/ ? I guess we can’t ship dual-boot enabled bootloaders since they would contain copies of the original firmware? But I could provide patches for the manual describing how to use dual boot (and possibly how to build a dual-boot bootloader yourself using mkboot) nevertheless. Anybody interested?

1. [Critical] If we’re compiling the single-boot RB bootloader, FLASHORIG should stay 0×00010000.
2. The jmp .actualcrt0 is unneeded.
3. As I said before, you can drop the RTC alarm check (tst.b 0×3000000) and update bsig[] accordingly.
4. We should also verify whether the OF is X5/X5V or M5 since otherwise the main LCD won’t work.
5.
I think that mkboot should be separated to mkboot.iriver and mkboot.iaudio (and preferably have a consistent naming scheme for other mkboot’s as well) and have a script named mkboot that will launch the appropriate mkboot.$platform . There’s no reason to compile the iriver code if you don’t have one.
6.
About bootloader distribution, I think we should follow the iriver way – http://www.rockbox.org/twiki/bin/view/Main/ManualRockboxInstall#iriver_jukeboxes Basically it says something like “download OF from its original site and apply fwpatcher to it”.
RButil should do it for the user automagically.

Anyway, in less than a day someone will upload a precompiled version to iaudiophile.net (or somewhere else) :)

1. Ooops, I knew I forgot something. Fixed.
2. Done
3. The current code works fine for me and as long as Rockbox doesn’t have official RTC alarm support, I’d prefer to keep it as it is. As soon as  FS#7814  is commited, I’ll happily remove the RTC test.
4. I don’t get this point. The only thing we care about in the OF is the fact that we can jmp 0×10010 to run it, is this different on the M5? How is the dualboot patch related to the main LCD?
5. I don’t have a strong opinion about this. As soon as somebody decides what’s the right way to go, I’ll happily follow.
6. Windows not spoken here, so I don’t know how fwpatcher works. And I never used rbutil, so the best I can do is to document how to use dual boot, assuming that it somehow magically got enabled using fwpatcher, rbutil or some illegal patched OF.

Thanks for all your work towards getting this patch committed.

3.
Another thing that might help is to *set* 0×3000000 before booting OF.
This might fool OF to think it woke up due to RTC alarm, circumventing the need for holding POWER for it to boot properly.
4.
Since all OF versions of all iaudio platforms have this jmp 0×10010, one might erroneously patch an OF for M5 with a RB bootloader for X5. It would install OK on the M5, but when RB bootloader is launched, it would use the wrong method to write to the LCD (the X5 way).
I know this is PEBKAC, but we should try to avoid it anyway.
6.
s/fwpatcher/mkboot/ .
The point is that we tell the user where to get the OF and have her patch it with RB bootloader.
I would appreciate it if you could write user documentation. Don’t forget to mention how it works from USB/charge mode.

Loading...

Available keyboard shortcuts

Tasklist

Task Details

Task Editing