Surfans F20 "NAND open error"

[amachronic]

I hate to revive the thread, but I don't think that's the case. I got a new unit today with the 2.7 FW and it seems like it has yet another flash chip. [...]

Here's an updated bootloader (v7) with support for the GD5F1GQ4xExxG. Upload a full dump (debug tools > dump entire flash, zip the resulting flash.img). Or check it yourself by comparing against uboot.bin in the OF image.

kaas, twotoneblue - could either of you provide another dump with the v7 bootloader to ensure it still works with the Winbond flash? I made a couple tweaks, which shouldn't have broken anything but it's a good idea to test again just in case. Thanks.

[JosephM]

I hate to revive the thread, but I don't think that's the case. I got a new unit today with the 2.7 FW and it seems like it has yet another flash chip. [...]

Here's an updated bootloader (v7) with support for the GD5F1GQ4xExxG. Upload a full dump (debug tools > dump entire flash, zip the resulting flash.img). Or check it yourself by comparing against uboot.bin in the OF image.

kaas, twotoneblue - could either of you provide another dump with the v7 bootloader to ensure it still works with the Winbond flash? I made a couple tweaks, which shouldn't have broken anything but it's a good idea to test again just in case. Thanks.

Wow, that was fast, thanks so much!!

I'm not sure how to compare it against the uboot.bin, they're wildly different sizes, so I assume I would need to extract the bootloader. But here's the link https://drive.google.com/file/d/1OzyUtGlceIe7iKbYWZ-6JZ3-h2MjnyMJ/view?usp=sharing.


I should add, I'm also able to take a bootloader backup and there are some strings in it that make be think it's not total gibberish. And I'm able to boot the native firmware.

I also checked the dump of of_player.img against the one posted earlier in this thread and they hash the same. Compared to the whole flash image shown earlier in this thread, the binwalk output is identical (though the files do differ), so I'm pretty much convinced that it is working, so I'm going to install the bootloader.

[amachronic]

Your dump is mostly OK and matches up with twotoneblue's dump and the vanilla FW images, except the first 4 pages (up to offset 0x1fff) are zeroed, and that's definitely a problem. Could you check if the bootloader backup is zeroed in the same way? The first bytes should be 06 05 04 03 02 55 aa 55 in a good dump (the same as what is shown in the SFC params).

[JosephM]

The bootloader doesn't appear to be zeroed in the same way, but those aren't the first few bytes. https://drive.google.com/file/d/16PQF--F50bQDUA247X2nKnnlN6_DvHpC/view?usp=sharing

Code: [Select]

0000000 0506 0304 5502 55aa 6300 0202 2fa4 0000
0000010 0000 0000 0000 0000 0000 0000 0000 0000
*
0000800 8007 4002 0000 0000 0002 3442 8007 4082

I also tested installing the rockbox bootloader last night. That worked. I just tried restoring from my bootloader backup and that worked perfectly too.

[amachronic]

The bootloader doesn't appear to be zeroed in the same way, but those aren't the first few bytes.

Code: [Select]

0000000 0506 0304 5502 55aa 6300 0202 2fa4 0000
0000010 0000 0000 0000 0000 0000 0000 0000 0000
*
0000800 8007 4002 0000 0000 0002 3442 8007 4082


That's good, and the bytes are the same; you're looking at 16-bit little endian values, effectively swapping every pair of bytes.

I also tested installing the rockbox bootloader last night. That worked. I just tried restoring from my bootloader backup and that worked perfectly too.

Did you do the bootloader backup or the full dump first? If you don't mind, could you also try a few bootloader backups from USB boot and inspect each one, and see if any of them get zeroed? (to check if this a transient error that pops up "randomly" or does it occur predictably on the first dump.)

[JosephM]

Lol, whoops, don't know how I missed that it was just little endianed.

As for the dumps I did the full dump first. But I also did subsequent bootloader dumps on fresh boots and they were all the same. And now I can't recreate the problematic full-flash dump (I tried four or five times).

When checking all the files, I noticed that the OFNI flash info file from that same boot was also zeroed. So maybe in the shuffle of files between devices and unplugging without unmounting, etc, the filesystem got corrupted? (I have since wiped and reformatted the drive since b/c I was getting weird errors.)

[amachronic]

So it's probably a filesystem error and nothing wrong with the flash, thank you for investigating.

[twotoneblue]

kaas, twotoneblue - could either of you provide another dump with the v7 bootloader to ensure it still works with the Winbond flash? I made a couple tweaks, which shouldn't have broken anything but it's a good idea to test again just in case. Thanks.

Dear all,

Apologies for not seeing the updates here - for some reason the notification didn't reach me. Here is the usual package with the v7 bootloader: https://drive.google.com/file/d/15Tw912xBi0yB0LDxorQVqi4igAxwtAQg/view?usp=sharing

There are a few differences - I believe you can make more sense of them than me.

Thanks for your continued investigations, everyone!

[Ren]

I bought a Surfans F20 Player as well and I want to install the native port on it.
I wasn't able to make a backup of the original bootloader with the bootloader provided from the wiki => "NAND open error (5).
 
I read through this thread that i stumbled upon when I searched for the error above.
I booted into bootloader-v7.erosq (from linux) and made a flash.img dump, flash_info.txt and a flash_onfi_info.txt using the debug tools of the v7 bootloader.
Here are the fileshttps://mega.nz/file/GCoF2DzS#KPCE35PTVlo6Twy3H3Qa5tdvrd1DiP4syjynI1O22LU.
I hope this helps in getting the natitve build stable on the SURFANS F20?!
Is it save to proceed with the installation of the native port with the latest (v7) bootloader from this thread?

Flash info:
readID opcode  = FF C8 D1 C8
readID address = C8 D1 C8 D1
readID dummy   = D1 C8 D1 C8
sfc params0  = 06 05 04 03
sfc params1  = 02 55 AA 55
sfc params2  = 00 63 02 02
sfc params3  = A4 2F 00 00

flash_onfi_info:
signature = FFFFFFFF
revision = FFFF
manufacturer = "ÿÿÿÿÿÿÿÿÿÿÿÿ"
device model = "ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ"
JEDEC mf. id = FF
data bytes per page = 4294967295
spare bytes per page = 65535
pages per block = 4294967295
blocks per lun = 4294967295
number of luns = 255
bits per cell = 255
max bad blocks = 65535
block endurance = 65535
programs per page = 255
page program time = 65535
block erase time = 65535
page read time = 65535

edit:
I installed the ROCKbox native port from the v7 bootloader, after a success message I first booted into ROCKbox from the BOOT Menue, this worked.
Then I rebooted and I just got a flickering screen.
So I powered the device off by long pressing power.
A new press on power just gives me the flickering screen again...
So I loaded the v7 bootloader from command promt again...
I reinstalled ROCKbox and powered off after.
I pressed power again and all I got is a flickering screen again.
So I started the bootloader again and created a Flashdump and the info files again.
here are they https://mega.nz/file/jTQS1K6Y#2OMx0mlbN7KqH24NBsz7AEeZqBCtWyXwTirj_9ecDxM

Then I restored the original bootloader. Now the player is working again with its original Firmware (not with ROCKbox sadly). I hope you will have success in getting the thing working with ROCKbox! If you need something else from me I try to provide it to you.

[amachronic]

I bought a Surfans F20 Player as well and I want to install the native port on it.
[...]
Is it save to proceed with the installation of the native port with the latest (v7) bootloader from this thread?
[...]
Flash info:
readID opcode  = FF C8 D1 C8
readID address = C8 D1 C8 D1
readID dummy   = D1 C8 D1 C8
[...]

This shows you have the GigaDevice flash (same as JosephM's) so yes it's safe to install with the v7 bootloader.

I installed the ROCKbox native port from the v7 bootloader, after a success message I first booted into ROCKbox from the BOOT Menue, this worked.
Then I rebooted and I just got a flickering screen.
So I powered the device off by long pressing power.
A new press on power just gives me the flickering screen again...
So I loaded the v7 bootloader from command promt again...
I reinstalled ROCKbox and powered off after.
I pressed power again and all I got is a flickering screen again.
So I started the bootloader again and created a Flashdump and the info files again.
here are they https://mega.nz/file/jTQS1K6Y#2OMx0mlbN7KqH24NBsz7AEeZqBCtWyXwTirj_9ecDxM

Then I restored the original bootloader. Now the player is working again with its original Firmware (not with ROCKbox sadly). I hope you will have success in getting the thing working with ROCKbox! If you need something else from me I try to provide it to you.

I don't know what the issue is, but if you try a few things it might help narrow things down:

• Go into the bootloader menu (hold volume up when powering on) and boot Rockbox - see if the LCD flickers
• Boot the original firmware from the bootloader menu - check if the LCD works
• Boot the original firmware by holding PLAY when powering on

Also if you could explain what you mean by the screen "flickering" that would help. Can you see the Rockbox logo or menus? Do they look corrupted? Or do you see randomly colored "noise"? Better yet, post a video of the problem if you can. It doesn't have to be great, as long as the problem is visible.

[Abscissa]

I bought a Surfans F20 Player as well and I want to install the native port on it.
[...]
Is it save to proceed with the installation of the native port with the latest (v7) bootloader from this thread?
[...]
Flash info:
readID opcode  = FF C8 D1 C8
readID address = C8 D1 C8 D1
readID dummy   = D1 C8 D1 C8
[...]

This shows you have the GigaDevice flash (same as JosephM's) so yes it's safe to install with the v7 bootloader.

FWIW, it appears that I have the same one, too. (Also a v2.7 Surfans F20.)

In my case, I installed the v2.5-based hosted (not native) version of rockbox. (See my second post over here: https://forums.rockbox.org/index.php/topic,54280.msg250792.html ) Seems to work as expected for me. As expected, the line-out no longer works (in either rockbox or the original player), but other than that rockbox seems to work fine. That said, I HAVE been experiencing some occasional quirks, maybe bugs, here and there, but nothing that seems likely (IMHO) to be related to the minor hardware/software mismatch between v2.5 and v2.7 (more likely related to my large, chaotic song collection, and maybe my settings preferences, pushing some of rockbox's limits the wrong way). I *am* taking notes though, so that I can narrow them down and file any issues as appropriate.

NOTE: Everything that follows in the rest of this post is most likely ENTIRELY UNimportant! I'm only making note of it here just because I happen to find it interesting...

Ok, so, as I mentioned here ( https://forums.rockbox.org/index.php/topic,54280.0.html ), I did a diff between the bootloader image that was pre-installed on my device (backed up via jztool before I flashed ANYTHING), versus the bootloader image in the official (non-rockbox) v2.7 .upt update file.

I can post links to my actual backed-up pre-installed bootloader image, and/or the output of radiff2's comparison, if anyone happens to be interested (and if it's kosher here - I don't want to open up any potential "legality" cans-o-worms I might not know about)

I got hold of radiff2 and looked at the diff it gave me. The way it shows things isn't really how I'm accustomed to looking at differences, so fwiw, I just stuck with my usual tool, Beyond Compare, and did a hex comparison in that.

Not really knowing what in hell I'm looking at, but having been told that *some* differences are apparently expected, I'm sufficiently convinced (99%-ish) that my dump was succesful and without error. It seems mostly the same as the official distributed image, and there's a fair amount of pattern to the differences that do exist. It's these patterns in the differences that I find interesting (albiet, unlikely to actually be significantly important for rockbox, I would imagine).

The differences, FWIW:

- Whatever kind of header this uses had a couple of bytes different: At addresses 0x0009 and 0x000C. Header stuff, so probably no big alarm.

- After that, everything up through address 0x0900 is identical.

- Between addresses 0x0900 to 0x2C88, it's all peppered with occasional single-byte differences. But what's interesting is that the vast majority (all?) of the bytes which are different, have values that are EXACTLY +0x10 greater in my dump as compared to the "official". Seems likely a changed offset?

- In the 48 bytes from 0x2CA0 to 0x2CD0, there are several bytes different. Mostly very close to their alternate values, within a difference of about +/-6 for most of them. Maybe some kind of sub-header?

- Very shortly after that, my dump has the following 16 bytes *inserted* (in comparison to the official image) at address 0x2D08:

C8 51 00 00 18 00 00 00 C8 51 00 00 18 00 00 00

This insertion of 16 bytes in my dump (vs "official") would seem to (likely?) explain all the earlier, presumable "offset" values being EXACTLY 0x10 greater in my dump (vs "official"). Maybe those values were (either directly or indirectly) referencing things within the chunk that begins here.

- After that, there's some identical data, and then a block of all-0xFF on both images starting at 0x2FB4. But the all-0xFF block is longer on the "official" image. The last, roughly quarter, of this all-0xFF block in the "official" image is replaced in my dump with various data (Maybe about a third or so of them are zeroes, though.)

- Then there's a big block of identical data from addresses 0x4004 to about 0x6004.

- From 0x6004 to the end of my dump (at 0x1FFFF), the data is mostly identical, but peppered throughout with occasional single byte differences, and also some two-byte words that are different. But even these differences seem to have some patterns:

For the single-byte differences: These mostly (maybe entirely?) have the exact same low 4-bits between both versions. It seems to mainly be the upper 4-bits that are different. There might be further pattern to that too, but I'm not sure yet.

For the two-byte words that are different (these are notably less numerous than the single-byte differences, but there's still a lot of them): For the first byte of the pair (the byte with the lower address), the low (less-significant) 4-bits tend to match and the upper (more significant) 4-bytes tend to differ. For the second byte of the pair (the byte with the higher address), it's reversed: The high 4-bits tend to match, and the low 4-bits tend to differ.

[Ren]

I don't know what the issue is, but if you try a few things it might help narrow things down:

• Go into the bootloader menu (hold volume up when powering on) and boot Rockbox - see if the LCD flickers
• Boot the original firmware from the bootloader menu - check if the LCD works
• Boot the original firmware by holding PLAY when powering on

Also if you could explain what you mean by the screen "flickering" that would help. Can you see the Rockbox logo or menus? Do they look corrupted? Or do you see randomly colored "noise"? Better yet, post a video of the problem if you can. It doesn't have to be great, as long as the problem is visible.

I made 2 videos of the issue as requested. Maybe seeing it yourself says more than me making a lot of words trying to describe the flickering.

Greetings Ren

[Oscar]

I made 2 videos of the issue as requested. Maybe seeing it yourself says more than me making a lot of words trying to describe the flickering.

Just a wild guess. Could it be, that you have installed the original "bootloader.erosq". When you install the bootloader from the Rockbox recovery menu (the bootloader which you have started with jztool), you will actually install the file "bootloader.erosq" from your SD-card. This file has as well to be the version 7 bootloader. So you have to copy the file "bootloader-v7.erosq" to the SD-card and rename it to "bootloader.erosq" before installing the bootloader. As said this is just a wild guess.

[Ren]

I made 2 videos of the issue as requested. Maybe seeing it yourself says more than me making a lot of words trying to describe the flickering.

Just a wild guess. Could it be, that you have installed the original "bootloader.erosq". When you install the bootloader from the Rockbox recovery menu (the bootloader which you have started with jztool), you will actually install the file "bootloader.erosq" from your SD-card. This file has as well to be the version 7 bootloader. So you have to copy the file "bootloader-v7.erosq" to the SD-card and rename it to "bootloader.erosq" before installing the bootloader. As said this is just a wild guess.

Thanks, that was really a lucky wild guess! I thought the v7 bootloader would install the v7 when the player booted into it. I still had 3 different versions of the bootloader on the sd. I didn't expected that to be a problem.... But it turned out to be one. Thankfully the problem is resolved now!
Thanks again!

[kaas]

I hate to revive the thread, but I don't think that's the case. I got a new unit today with the 2.7 FW and it seems like it has yet another flash chip. [...]

Here's an updated bootloader (v7) with support for the GD5F1GQ4xExxG. Upload a full dump (debug tools > dump entire flash, zip the resulting flash.img). Or check it yourself by comparing against uboot.bin in the OF image.

kaas, twotoneblue - could either of you provide another dump with the v7 bootloader to ensure it still works with the Winbond flash? I made a couple tweaks, which shouldn't have broken anything but it's a good idea to test again just in case. Thanks.

I just installed native rb using this bootloader (the same as currently in the wiki), the bootloader backup looked good (first few bytes are as you describe in your other posts, after that it is zeroed up to about 0x800 but I checked against the original firmware and it's the same there), then I booted rockbox successfully from the recovery menu, then installed, moved over all my settings/themes etc from the hosted port, and presto, works like a charm. Many many thanks Amachronic and everyone else who worked on this! It solved my main problem with the hosted port, namely that the device would hang for a few seconds when opening the file browser for the first time since booting, and dare I say that everything feels just a tad snappier?