Update: a new program to rebuild the SPI flash memory contents

In my previous post here I proposed a program that was able to create the SPI flash memory contents for an Android tablet, starting from U-boot.bin and W-load.bin taken from FirmwareInstall folder of a working, original or modded, firmware rom. The previous program had a limit : the environment variables (and the boot script that is stored in the same space) were not used in the creation of the my-spi.bin output file, so when you re-program the SPI flash memory with the file produced by the old program, you must supply the needed instructions to upgrade the system via serial terminal.

Now, the new version adds the full environment variables and the necessary CRC32 code to the output file my-spi.bin, making the file much more useful and easy to use. Obviously, while in the first version you had to supply only two “input” files (u-boot.bin and w-load.bin), now you must supply a third: the env_uboot, that can be found on the FirmwareInstall/env/ folder or the usual, working, firmware distribution related to the tablet.

The instructions for use are exactly the same as for previous version, just add the env_uboot file in the program folder. As usual, the program was written in FreeBASIC and compiled under Win7. It doesn’t require installation, just unzip the downloaded file in a folder, and add the needed input files, then start the application…. that’s all. Hope this will be useful for someone ๐Ÿ™‚

Download the zip file at this link.

The memory areas of the resultant my-spi.bin files are:

0x00000 to 0x5FFFF reserved for u-boot.bin
0x60000 to 0x6FFFF reserved for environment variables
0x70000 to 0x7FFFF reserved for w-load.bin

Remember to get the right w-load—.bin file from the FirmwareInstall folder.
Generally, in most of the tablets I’ve seen (but NOT in all), the right one has the string DDR3_700M_1066M_8bit_2_256MB in the filename. Obviously, when you copy this file in the application folder, you must rename it in w-load.bin, ‘cause the program looks exactly for that file name.

7 thoughts on “Update: a new program to rebuild the SPI flash memory contents

  1. Hey Robotop,

    Nice job on the update of the SPI program, I think I will use this one to revive my bricked wm8650 ๐Ÿ™‚ The sd slot spring isn’t (as you know very well) of great quality, so the spring that must push out the sd card didn’t work properly, it pushed it out real slow… slow enough to just start the update and disappear, bricking my tablet.

    Hehe, your apps always have such small size, awesome! Freebasic FTW ๐Ÿ™‚

    Thanks for the updated version mate!

    HcH

  2. Hi
    Since I discovery your blog, by HcH forum, I took 2 tablets with WM8650.
    One of those, dont power on, and analyzing the SPI file I saw all the first line with FF. I working to reconstruct the SPI.
    BUT
    The another tablet, with the same symptoms, the SPI it seems ok. BUT, the address of ENV_UBOOT are diferent, in another address.
    Can it be possible??
    Do you wanna like to see the rd_spi.bin ???

    Sorry my english

  3. Hello Daniel, there are TWO copies of “env variables” on the SPI flash memory. One is at address 0x50000 (I’m speaking about the address inside the SPI chip itself, in the system the address is 0xFFF80000 + 0x50000), the other address is at 0x60000 . The reason for this double copy, in my opinion, is to have a “backup” in case of damages. The “env variables” are really important (the tablet can be locked in case of data corruption), so if a copy is damaged (the first 4 bytes of the block are used to store the CRC32) the system can use the other one, and if this is valid, the corrupted one can be recovered thanks to the backup. This is my opinion, but I haven’t read the “real” program. I think this opinion will be valid, ‘cause the DOS FAT (File Allocation Table) has the same mechanism, with two copies of files allocation to avoid data errors that can made files “lost” (and this time I’m sure, ‘cause I wrote a floppy disk control program on a microcontroller about 15 years ago ! ) . Looking on WM8505 tablet (old one) I noticed that the u-boot was more “rich” and speaded over the 0x50000 block, so I think the “main copy” of the “env variables” is the one at address 0x60000 and the other is the backup.
    If you want, you can send the rd_spi.bin (ZIPPED !) using the form for file sending in the “home page” of the bolg. I will take a look… ๐Ÿ™‚

  4. I send the archive spi.rar

    Before send to you, I look the spi.bin and I saw the env_uboot exactly you said in post. But using the spi_spilt.exe, the env_uboot open entire FF.

  5. Hello Daniel, the “spi_split” program uses the 0x60000 area to extract the env_uboot variables, so if this area is corrupted, may be there is no output. I’m thinking to modify the program to generate TWO different env_uboot files using BOTH 0x50000 and 0x60000 areas. In the meanwhile, waiting for my program update, you can use any hex editor (my favourite one is “Frhed”) to make a “copy and paste” on the rd_spi.bin file, copying the “valid” area and pasting to the wrong one ; once the copy is done, launch the “spi_split” program and the env_uboot file will be valid.

    Edited: I just downloaded the file. The situation is exactly as I described here. Your “valid” env_uboot variables are in the 0x50000 area ; that’s not normal, but, may be, something strange happened… ๐Ÿ™‚

  6. ok.
    I will try this tomorrow.

    PS: I take a look in one GOOD SPI, and I saw in
    x50000 one ENV different then x60000 ENV.
    I am wrong, or they are different, litlle different??
    In Frhed, he show 80 different’s areas.

    I’m noob in programming, sorry.

  7. Hello Daniel, you’re right for the differences, but there are two points to consider: the first is that the LAST valid “env variable” is the one that’s followed by two successive zeroes (may be some old variable is still written as text AFTER the end-of-file that’s signed by the two zeroes) ; the second is that the “order” of “env variables” isn’t always the same. For example, you can find :
    setenv wmt.display.logoaddr 500000
    setenv wmt.display.logoaddr2 550000
    in the zone 0x50000 and:
    setenv wmt.display.logoaddr2 550000
    setenv wmt.display.logoaddr 500000
    in the zone 0x60000 ; this will give a “binary difference”, but there is no difference in “env variables”.
    I repeat myself… I don’t know HOW the backup copy is handled by the program, may be the “copy” isn’t done on a binary basis, but using some other criteria. The important thing, however, is that all the USED variables have a backup copy.
    Also note that if you, using the serial terminal with U-Boot, type a command like, as example :
    setenv wmt.audio.spi
    saveenv
    so, you used a “env variable” name WITHOUT any data, you will REMOVE such “variable” (wmt.audio.spi in the example).
    The saveenv command WRITES the new situation of “env variables” on the SPI flash memory and updates the crc32 in the first 4 bytes.

Comments are closed.