Installation / Removal > Other - Installation/Removal

Surfans F20 v2.7: Getting started (pardon my initial caution!)

(1/1)

Abscissa:
Ok, so I now have a Surfans F20 in-hand, and I've verified through the pre-installed firmware what I expected - it reports itself as v2.7. My understanding, IIUC, is that this device, or at least this iteration of it, seems to be sort-of somewhere in between "experimental" and "out-of-the-box" support from Rockbox? It's been...quite a few years...since the last time I used rockbox (let alone installed it)...so at least for just getting started, and getting at least some form of rockbox running, I'm trying to be extra-careful and try to avoid too much guesswork or assumptions, at least just for starters...

Ok, so...factory new Surfans F20 v2.7. First round "getting started with rockbox" would seem to be trying the rockbox installer. For me, this would be the "Linux (64-bit x86)" version (on Manjaro, personally). I'm not familiar with "AppImage", but I seem to be able to run the installer and its GUI anyway. It seems to want an image of my original firmware's bootloader. Should I just grab and use the "bootloader.erosq" image from ( https://download.rockbox.org/bootloader/surfans/f20.zip ) even though the links to it on ( https://www.rockbox.org/wiki/AIGOErosQK ) say that it's for v2.2 and v2.5? Or should I instead do...something?...to extract the bootloader from my device? Or...should I just not be bothering with the rockbox installer at all and do something else entirely for a manual install? (Although when I look at the "Rockbox Manual Install" page at https://www.rockbox.org/download/byhand.cgi I don't see any links for this device or for any of its "siblings", like the Aigo Eros or Hifi Walker, etc...)

Based on the first couple posts in the thread here: ( https://forums.rockbox.org/index.php/topic,54228.0.html ), it sounds like I should just go ahead and use the bootloader image in the zip listed for v2.2/v2.5, but I wanted to ask here first to be sure. It also sounds from that thread that I should install the bootloader manually without using the rockbox installer, and I may very well be overlooking something obvious, but I'm not seeing documentation on how to do that.

So again, pardon my newbie questions, but I just wanted to double-check on all my initial steps here and make sure I didn't do anything too terribly stupid straight out of the gate.

amachronic:
Installing the bootloader with a .upt file should work exactly like flashing the original firmware, that will give you the "hosted" port which runs on top of the original firmware's Linux kernel. speachy prepared a patched v2.7 .upt image in this thread but it hasn't been tested yet.

Using the patched v2.5 image is also possible, I think -- but line out will not work in the original firmware or Rockbox. IIRC whoever tried that was able to revert back to vanilla v2.7 afterwards. Line out definitely doesn't work in Rockbox no matter what, unfortunately, the hardware and ALSA controls have apparently both changed since the previous hardware revision.

If you want to use the "native" port you should follow the jztool install instructions on the wiki for installation, but use the v7 bootloader from this thread, not the release bootloaders linked on the wiki page.

Abscissa:
Thanks. I think the main mistake I made was trying to dive into this before actually checking the Surfans website to see how updating the official (non-rockbox) firmware is even done in the first place (my other mistake was trying to do this entirely too late at night!!) After taking care of all that, and getting hold of the device's official firmware update files, things started making more sense to me. (And looking back now, I see my previous post above was...very confused. So nevermind that post now!!)

As I'm understanding things now, the .upt image files are the standard firmware update file format for this particular device (and all the other Aigo ErosQ/K-based ones), and isn't really a rockbox-specific filetype, right?

Ok, so I was able to get jztool working and running the v7 bootloader on my device. I used it to make a backup of my pre-installed bootloader and stored it away elsewhere. I'm not sure how to extract the bootloader from the official (non-rockbox) .upt file (or if that's even something we're able to discuss here) so that I can verify they match (just for my own peace of mind).

I didn't do anything else via jztool just yet. But I did go ahead and try installing the patched v2.5 .upt image from the option in the original firmware. That seems to work exactly as expected - I get a boot menu to choose between rockbox, or the stock player, or a small util suite (which I noticed also lets me invoke the firmware update process, which is nice). The stock player, as expected, now reports v2.5 instead of v2.7 and no longer outputs anything through line-out. It looks like installing the actual rockbox player software is separate from that .upt installation...which all makes sense to me now: If I understand correctly, the .upt images are updates for the device's internal flash memory, which stores both a bootloader and the stock (non-rockbox) player software. That bootloader can be either stock, or one that's been patched with the ability to run rockbox, which is stored on the SD card.

So I went and tossed rockbox onto the SD card (I used Rockbox Utility to do this, just to try it out that way. I unchecked the bootloader option, since I'd already installed it directly.) Aside from the line-out issue of course, rockbox is running fantastically now for me too. And I guess, the way I have it set up right now, rockbox is running hosted, not native, right?

Ok, so my questions now, before I go trying out any other images, or native, or anything just yet:

1. Regarding both the device's USB boot mode, and also the device's flash update process: Do we know whether those abilities are stored as part of the bootloader in the internal flash (and could potentially get clobbered by a bootloader update gone wrong, bricking it), or whether they instead live somewhere lower-level that can't get nuked by a bad flash update? (Although, it seems unlikely to me that the flashing process would live on a lower-level than the bootloader since it would require at least the ability to read a fat32 filesystem. Maybe exfat, too. The usb boot mode would seem more likely to be safe from a bad update, but I wouldn't really know for sure.)

2. Are we able to discuss extracting the bootloader from a .upt file so that I'd be able to double-check the backup I made?

amachronic:

--- Quote from: Abscissa on August 07, 2022, 04:56:34 PM ---[...]
Ok, so my questions now, before I go trying out any other images, or native, or anything just yet:

1. Regarding both the device's USB boot mode, and also the device's flash update process: Do we know whether those abilities are stored as part of the bootloader in the internal flash (and could potentially get clobbered by a bootloader update gone wrong, bricking it), or whether they instead live somewhere lower-level that can't get nuked by a bad flash update? (Although, it seems unlikely to me that the flashing process would live on a lower-level than the bootloader since it would require at least the ability to read a fat32 filesystem. Maybe exfat, too. The usb boot mode would seem more likely to be safe from a bad update, but I wouldn't really know for sure.)

--- End quote ---
USB boot mode is part of the CPU boot ROM, it's baked in hardware and can't break due to a failed firmware update. So you can always recover the bootloader with jztool, or with Ingenic's own flashing tools if you can figure out the parameters or badger the manufacturer into telling you.


--- Quote ---2. Are we able to discuss extracting the bootloader from a .upt file so that I'd be able to double-check the backup I made?

--- End quote ---
The .upt file is just an .iso, rename it and mount or extract it as you wish. Inside you'll find uboot.bin. The bootloader backup is just a straight dump of the first 128k of your flash which corresponds to the first 128k of uboot.bin. Unfortunately verifying your backup isn't totally straightforward because the data in the update image will be different from what's on your flash -- some parts like the flash partition table are deliberately left out of the .upt image, and apparently Ingenic's updater leaves random garbage in some unused parts of the flashed image, which makes hashing the images impossible.

I just diff images with radiff2 -x and check if things look "reasonable," never bothered to write any tool to verify backups. Off the top of my head the only differences should be around 0x200-0x7ff, 0x3c00-0x3fff and maybe the uboot environment block.

Abscissa:
Excellent, thanks!

From what I can tell, my backed up boot image seems, at least to me, to likely just be a different version of the one from the official uboot.bin. More similar than different, and the differences seem to have some interesting patterns.

But at this point, I'm clearly no longer in the realm of "Installing Rockbox" so I should probably move to a different subforum for further discussion. Would this thread be the appropriate place?: https://forums.rockbox.org/index.php/topic,53601.0.html

Navigation

[0] Message Index