Notice: A non well formed numeric value encountered in /sites/ on line 96 Notice: A non well formed numeric value encountered in /sites/ on line 96 Notice: A non well formed numeric value encountered in /sites/ on line 96 Deprecated: Function create_function() is deprecated in /sites/ on line 104 Deprecated: The each() function is deprecated. This message will be suppressed on further calls in /sites/ on line 845 Deprecated: Function create_function() is deprecated in /sites/ on line 111 FS#9778 : Single Mode Bootloader fails reboot on updated Gigabeat S.



FS#9778 - Single Mode Bootloader fails reboot on updated Gigabeat S.

Attached to Project: Rockbox
Opened by Davide (Davide-NYC) - Saturday, 10 January 2009, 17:27 GMT
Last edited by Torne Wuff (torne) - Sunday, 01 November 2009, 19:30 GMT
Task Type Bugs
Category Bootloader
Status Unconfirmed
Assigned To No-one
Operating System Gigabeat S
Severity Low
Priority Normal
Reported Version Version 3.1
Due in Version Undecided
Due Date Undecided
Percent Complete 0%
Votes 0
Private No


I used the official toshiba updater to get an "original" fresh install on my beast and then attempted to run through the install procedure for a single boot rockbox install. After a (seemingly) sucessful install I'd end up in recover mode after any reboot.

Fatal error when attempting to install nk.bin (rockbox only bootloader) using sendfirm in Windows to an updated (v1.2) Gigabeat S player.

After install of both bootloader and rockbox the Gigabeat S, once rebooted, goes into recovery mode (toshiba) and requires an update/restore. This is the Number 3 Triangle.

Gigabeat was first updated using the official toshiba MESV12US updater. "gbs_update_1_2_us.exe"

Using SVN revision 19741 to compile nk.bin under WinXP and Cygwin.
Using of 7/4/2008 found on the wiki to send over the bootloader.

I suspect most devs updated their bootloaders using the sendfirm utility *before/without* updating the entire player with the updater utility from toshiba. Thus they started from a v1.1 OF and never updated any part of that.

Maybe the updater changes something in the bootcode. I don't know.
This task depends upon

Comment by Marc Guay (Marc_Guay) - Saturday, 10 January 2009, 17:33 GMT
I had the same experience just now switching from a dual-boot nk.bin to a single-rb-boot nk.bin (no toshiba OF update).
Comment by Snow "bunnyboi" Pawson (bunnytaur) - Sunday, 29 March 2009, 22:07 GMT
I am also experiencing this problem. I am using rockbox version r20559-090328 compiled using Slackware Linux 12.1. It did work fine with an earlier revision(I don't remember the exact one unfortunately.) after being flashed with the official Toshiba 1.2 updater, but took a few times and only worked with a dual boot of rockbox and the OF of the device.
Comment by Stephen (specto) - Sunday, 05 April 2009, 04:50 GMT
Same thing please fix this or tell me how to fix it. I absolutely love the rockbox firmware on this player, but I can't use it because it keeps loosing the boot loader.
Comment by Michael Sevakis (MikeS) - Sunday, 05 April 2009, 08:17 GMT
I tried an experiment to see if was just a filesize issue but the solution appears more complicated than that.

Davide: Correct. I purposefully avoided any sort of updater, anticipating the changing of the boot code to make it more picky. Mine doesn't have trouble with a single-boot bootloader and I don't plan on causing one with having only one device on hand. I use the beast in general as a player as well.

Snow: Are you saying that you did have a working single boot after running the 1.2 updater and that changed by using a different bootloader SVN revision? If so, it may be helpful to know exactly in what SVN revision the problem began.

So, I have yet to have anyone definitively state one of the following:

1) Single-boot breakage is tied to the 1.2 update and thus breaks for any SVN revision bootloader.
2) Single-boot breaks with the 1.2 update upon a certain SVN revision bootloader but works with some earlier one.

As long as you use a recent Rockbox firmware revision, which bootloader revision you use isn't very relevant for having Rockbox boot and run (not considering this problem). This is only because critical system setup was included in the firmware itself recently rather than relying on the bootloader alone. Testing an any older bootloader that includes bootloader USB mode+recent SVN should be ok.
Comment by Eric Jorgensen (EricJorgensen) - Sunday, 05 April 2009, 21:51 GMT
I've got this issue on one of my S30's as well. I have a little commentary to add, because i have 7 S-series gigabeats here in various states of repair.

I've observed, for example, that if i take a harddrive from an S30 running 1.2 and connect it to a board from an S30 that ran 1.1, the bootloader automatically flashes itself to the 1.2 version.

More importantly, it seems to work the other way as well.

I've also observed that there is a 1.3 firmware in the wild - a 3/3/09 update from toshiba - but I haven't installed it on anything.

If i use cabextract on the update exe from toshiba, both the 1.2 and 1.3 versions contain SUpdate.exe, NK.bin, Recovery,bin, and pmcboot_secure.bin. All three files are unique to their version in some sense - diff says they're different.

Pulling a harddrive from a v1.2 S30 which has never been rockboxed and sticking it into a usb enclosure, I find that NK.bin and Recovery.bin on the S30 are identical to those found in the updater.

I've also pulled a harddrive from a v1.1 S30 and copied off the NK.bin and Recovery.bin, and perhaps these can be shoehorned into the 1.2 update package to revert a 1.2 or 1.3 S30 to 1.1 firmware. Or at the very least they can be manually dumped on the 1.2 harddrive which may cause it to automatically flash the bootloader back to the v1.1 level. I have not tried this.

Searching around with google, it sounds like there has been a v1.1 firmware recovery tool in the wild in the past, but Toshiba no longer offers it for download. My google-fu is not good enough to find it yet.

I have however got a 15M 7z archive containing all the firmware files I've got, if anyone wants it.
Comment by Edoardo (e.feira) - Wednesday, 08 April 2009, 19:59 GMT
Ok, so I have a pseudo-solution...

If you run a chmod 200 on the nk.bin before sending it to the Gigabeat, it will reboot nicely with the single bootloader. I have no idea why because the nk.bin on the Gigabeat TFAT partition is in any case with rwx (700) permission, doesn't matter what the permissions were on the PC. However, if I do the same steps with different permissions on my PC, it fails. Go figure...

So, here are the steps:
- plug the power supply and TURN OFF the battery
- chmod 200 nk.bin
- reboot the Gigabeat
- send the nk.bin to the Gigabeat (standard)
- once in USB bootlader mode, run a fdisk (standard)
- on the data partition <TFAT_>, copy the .rockbox directory (standard)
- on the data partition <TFAT_>, copy the rockbox.tar file into the directory Content/0b00/00/ (less standard...)
- chmod 500 of the rockbox.tar so the it will remain there. Otherwise the player deletes it after the first time it uses it.
- reboot and you are ok

now, once you are in Rockbox, you can TURN ON the battery and use it normally. However, when powering it up, DO NOT connect the power charger until you are within rockbox.

I have no idea why but:
- if I shut it down when powered by the battery
- I turn it on with the battery,
==> It works

- if I shut it down when powered by the charger
- I turn it on with the charger
==> It works

BUT, a combination won't work! Say
- if I shut it down when powered by the battery
- I turn it on with the charger attached
==> It WILL NOT works

even more annoying, it will not recognize the bootloader anymore! Again, this is completely obscure to me but I know that when I do it, it doesn't work.

Hope I helped,

Comment by Michael Sevakis (MikeS) - Friday, 10 April 2009, 03:27 GMT
> Hope I helped,
> Edoardo

Quite possibly. Be sure you really found a pattern. This could indicate certain cleanups must be performed before powering down.
Comment by Marc Guay (Marc_Guay) - Thursday, 21 May 2009, 18:38 GMT
I have updated to OF v1.2 and building a single bootloader from r20089 works fine, r21017 does not. I'm going to try to track down where it broke.
Comment by Marc Guay (Marc_Guay) - Thursday, 21 May 2009, 18:59 GMT
Hmmm.. Perhaps it's not that simple. The one from r20089 doesn't always work. Very finicky. I can't find a pattern.

Update: I've tried all kinds of different combinations of dual-bootloader/single-bootloader/copy&paste/sendfirm/usb bootloader mode/rockbox usb mode and don't see anything. What baffles me the most is this series:

send dual-bootloader using sendfirm
usb bootloader mode
copy nk.bin (r20950) over
disconnect usb
works fine
reboot again
#3 triangle
Comment by Sylvan Mably (smably) - Friday, 14 January 2011, 07:34 GMT
I ran into this problem (inability to switch from dual-boot to single-boot with Gigabeat running OF v1.2) and was able to solve it using the Gigabeat 1.1 updater. This version is not available officially from Toshiba as far as I know, but it can be found quite easily by googling "". After reverting to 1.1, installing the single-boot bootloader was about as easy as you would expect.
Comment by Torne Wuff (torne) - Friday, 14 January 2011, 10:15 GMT
Thanks for the data point. Hopefully some day I will have time to look into this in more detail :)
Comment by Mustapha Senhaji (DrMoos) - Monday, 17 January 2011, 22:55 GMT
Indeed flashing to 1.1 solved the dualboot problem here to. (Better, single boot works like expected too).
The 1.2 and higher version seems to not like rockbox that much.
Thanks smably for your find, that seems indeed to be the solution about all the problems encountered for rockbox bootloader installation.

And like you said, as easy as it should be!!!!

Maybe it's time to update Wiki, and make the beast finally a stable port, after all...
Comment by Michael Sevakis (MikeS) - Tuesday, 18 January 2011, 04:51 GMT
Ok, I had asked a few times going way back if anyone tried this and never really got a "yes". I'm glad it works though.

It tells me there's an easy way back from an infected player, which makes me more comfortable about putting a 1.2 update on it if I want to get my hands really grimy on the beast again.

@Torne: I compared my own ROM dump and another's and a quick comparision (with a text editor file compare that actually still diffs the binary, rather than just 'diff' which only says they're different) seems to show that differences are fairly minimal from 1.1 to 1.2.
Comment by Dominik Riebeling (bluebrother) - Monday, 11 April 2011, 21:19 GMT