Installation / Removal > Other - Installation/Removal

Surfans F20 "NAND open error"

<< < (9/9)

Abscissa:

--- Quote from: amachronic on August 07, 2022, 10:06:01 AM ---
--- Quote from: Ren on August 04, 2022, 03:10:03 AM ---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
[...]

--- End quote ---

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

--- End quote ---

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:

--- Quote from: amachronic on August 07, 2022, 10:06:01 AM ---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 onAlso 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.

--- End quote ---

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:

--- Quote from: Ren on August 09, 2022, 03:39:35 PM ---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.

--- End quote ---
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:

--- Quote from: Oscar on August 09, 2022, 04:54:21 PM ---
--- Quote from: Ren on August 09, 2022, 03:39:35 PM ---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.

--- End quote ---
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.

--- End quote ---
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! :)

Navigation

[0] Message Index

[*] Previous page

Go to full version