Surfans F20 v3.4 - jztool doesn't seem to activate the screen

[jdharper]

Hello!

Over the weekend I tried to install Rockbox on a new Surfans F20. It shipped with firmware update 3.4, which is newer than what's available here. I've emailed Surfans support to see if they'll give me the stock 3.4 firmware, but in the meantime I tried to get into the bootloader menu with jztool and had no success. I tried this on two computers, one Windows and one Linux, and I tried it from both the chrome tool and the command line. In all cases, it would LOOK like it was working--no error messages from jztool, and the device would show up in device manager/lsusb as expected. But the screen stayed dark on the device.

I think that this version of the hardware may have a different LCD screen than previous models, maybe one that requires a different command to turn on? It looks to me like it's connecting but the screen isn't lighting up for me to actually do any commands.

I'm not sure how to fix that, but figured this is the right place to report the issue.

[dconrad]

Ok, thanks for the heads up. Once we get a 3.4 update file we can figure out what may be different. So you put it in usbboot mode (the blue led is on, screen is off), plug it in and run jztool to send the bootloader and... nothing happens?

[jdharper]

Correct. I load it in USB mode, the light is blue and the screen is off. Then I try to load the bootloader, the blue light goes off, but the menu never appears.

I have to push the power button for several seconds, wait, then push the power button again for several seconds again to make it turn back on in regular mode. Between that and the lack of errors, I'm assuming that it's loading the menu but never actually displaying it.

Here's the log from the jztools.js website:

Downloading: 'files/bootloader/aigo/native/221029-b4e7c60c6d/bootloader.erosq'
File downloaded, 92160 bytes
Extracting bootloader-info.txt...
Extracting spl.erosq...
Extracting bootloader image...
Found bootloader.ucl (v1 format)
Validated bootloader package.
Bootloader version: b4e7c60c6d-221029
Saving bootloader...
Asking for device...
Opening device...
Claiming device interface...
Loading stage1 (SPL)...
Pausing for SPL to come up...
Loading stage2 (bootloader)...
Closing device...
Done!

[speachy]

Here's the log from the jztools.js website:

Downloading: 'files/bootloader/aigo/native/221029-b4e7c60c6d/bootloader.erosq'

It appears that this jztools website is out of date.

It should be using the 20240908-a7cfee640d build, and there's also a different bootloader for different HW generations.

Strictly speaking it shouldn't be using a specific version at all; there are symlinks in place that will always point at the latest bootloader release.

[dconrad]

Correct. I load it in USB mode, the light is blue and the screen is off. Then I try to load the bootloader, the blue light goes off, but the menu never appears.

I have to push the power button for several seconds, wait, then push the power button again for several seconds again to make it turn back on in regular mode. Between that and the lack of errors, I'm assuming that it's loading the menu but never actually displaying it.

Here's the log from the jztools.js website:

Downloading: 'files/bootloader/aigo/native/221029-b4e7c60c6d/bootloader.erosq'
File downloaded, 92160 bytes
Extracting bootloader-info.txt...
Extracting spl.erosq...
Extracting bootloader image...
Found bootloader.ucl (v1 format)
Validated bootloader package.
Bootloader version: b4e7c60c6d-221029
Saving bootloader...
Asking for device...
Opening device...
Claiming device interface...
Loading stage1 (SPL)...
Pausing for SPL to come up...
Loading stage2 (bootloader)...
Closing device...
Done!

Speachy got to it before me, but:

Ah, I see. It looks like the web jztool is automatically pulling the old bootloader from an old url which appears to not exist anymore... Although you would think it should throw an error in that case. It's also curious that the blue light goes out though, that should stay on. Any chance you could use the desktop command line jztool? There's a chance that something is going sideways with the web jztool, and the hardware might not be changed (fingers crossed!). I would try loading this bootloader file.

BTW, thanks for noticing the version changed and being proactive about it   

Edit: Just saw that you already said you had tried the command line jztool

[jdharper]

I just tried the jztool again with the file you linked, just in case. Same result: as soon as I run the jztool command, the little blue light turns off, I get this message, and nothing happens after.

PS C:\Users\JD\Downloads> .\jztool.exe -v erosq load bootloader.erosq
[ NOTICE] Rockbox bootloader version: b4e7c60c6d-221029

Tried the same thing with the AIGO Eros Q hardware revision 3 bootloader from https://www.rockbox.org/wiki/JztoolInstall#jztool, and got the same result but with a different version number. The last digit is off by one from what's on the website but I'm assuming there's a typo on one or the other and that it's the right bootloader.

PS C:\Users\JD\Downloads> .\jztool.exe -v erosq load bootloader.erosq
[ NOTICE] Rockbox bootloader version: a7cfee640d-240909

[dconrad]

Ok, yeah something's definitely different then. The fact that the blue light goes off makes me think perhaps they're using a different power controller than the AXP192...? I hope not, hopefully it's a simple change. We can't really do anything until we get an update file though.

[dconrad]

The second set of numbers in the bootloader version is just the date, so that discrepancy is just Sept. 8 vs Sept. 9.

Well if you feel like messing with it, we can do a few tests:

 1) If you load up the bootloader with jztool (be sure to use the a7cfee640d-240909 version instead of the b4e7c60c6d-221029 version) and scroll 6 clicks to the right and then press play, the device should reboot into the original firmware. It's between "Shutdown" (5 clicks) and "Install or Update" (7 clicks). Fortunately, as long as you make sure the bootloader.erosq file is not on the card, there's no danger there. It would probably actually be easiest to do this test without the card in the device at all. This would confirm your suspicion that it's alive but the screen is just off.

 2) We should be able to dump the contents of the flash to the SD card. You would:

• load up the bootloader (use the a7cfee version)
• scroll about one whole revolution to the right (it's more important to never go left than it is to go precisely one revolution), then press play
• scroll about one whole revolution to the right
• scroll one click to the left and press play
• wait, let's say, 1 minute and 30 seconds
• reboot the player and hook it up to the computer to get the flash.img file

We could also do a few test builds where we try some different GPIO pins and see if we stumble on one that is changed.

[jdharper]

Hmm. No luck there after several attempts. Maybe it isn't just the LCD after all? Or maybe I'm missing my targets, it's hard to tell.

I did get an email back from Surfan's support with a google drive link.... that doesn't work and says I need to be authorized. Once I get a working firmware link I'll report back!

[jdharper]

They have gotten back to me with the 3.4 firmware.

Here's a link to it:

https://www.dropbox.com/scl/fi/pr3m32pnkcplr8o5mh26g/update.upt?rlkey=5szl2wnwy145n7y3e9jta87rl&st=c3thmu6s&dl=0

[speachy]

They have gotten back to me with the 3.4 firmware.

Thanks for doing that!

The native port is not an option on these players until we can figure out what changed; in the mean time, I patched their firmware updater so that the hosted port can be used:

   https://download.rockbox.org/bootloader/surfans/F20-v34-patched.upt

Please let us know if this works; follow the instructions in the wiki for the hosted port installation.

EDIT:  The v3.4 firmware image is incompatible with all ErosQ/K-series players; they will refuse to install it altogether.

[jdharper]

OK, progress!

The Firmware Upgrade tool accepted the patched file. Now when I boot up the device, I get a menu of options (Tools, Rockbox, or Hiby Player). Opening Hiby Player works, and opening the Tools menu gives me a list of options.

When I select Rockbox, the screen turns off and the blue light turns off. I recorded a video, and was able to catch the message "Battery Empty! Recharge! Shutting down!" The stock firmware says the battery is at like 60%.

I'm letting it charge overnight and we'll see what it looks like tomorrow. But that makes me wonder if that's what's been happening with the bootloader too, if it's been reading the battery as empty and shutting down immediately (even though it was plugged into my computer).

EDIT: Charged it overnight and it does the same thing now, Rockbox shuts down with a battery empty error even on a full charge.

[speachy]

When I select Rockbox, the screen turns off and the blue light turns off. I recorded a video, and was able to catch the message "Battery Empty! Recharge! Shutting down!" The stock firmware says the battery is at like 60%.

Ugh, that tells me this new base platform changed up how they report battery levels.

The good news is that the bootloader integration worked, so we have access to adb now.  If you can install 'adb' on your system, when turning the device on, go to Tools / ADB Start, then on your system, plug the player in and run 'adb shell' to get a shell on the device; then run 'find /sys/class/power_supply ' and send us the output.

[jdharper]

Here you go:

/sys/class/power_supply
/sys/class/power_supply/ac
/sys/class/power_supply/usb
/sys/class/power_supply/axp_battery

[speachy]

/sys/class/power_supply/axp_battery

Lovely, they renamed that.  Easy enough to fix.

Two more requests in the mean time:

From within the adb shell, can you send us the output of 'dmesg' and 'amixer contents' ?