Saving and Restoring Media Player Firmware from Vogue Magazine

    Experiments with the player from the Vogue magazine are very good, but the good old admin habit of making backups of everything and everything haunts me. For it is very easy to spoil a toy when experimenting with other people's firmware, but it is not clear how to return it to its original state. It will be a shame to spoil such a freebie.

    So, after a 3-day brain attack on this device, I have sorted out to the smallest detail the process of saving the native firmware and pouring it back. Special thanks to tronix286 for modifying the original usb_boot program, adding the ability to read firmware to a file, and for throwing a couple of useful datasheets into it.

    Everything necessary for flashing and restoring the player to its original state is here .
    Actually in the archive, a working and customized version of usb-boot for the log + firmware files.

    For the most impatient, I will immediately describe the recovery process: -
    disconnect the battery from the player, or insert a piece of paper under the contact of opening the page;
    - press the button on the player and hold down the button, insert the usb cable and release the button;
    - the computer determines a new device, install drivers for it from the archive, the device icon remains in the form of a question, but don’t be scared, it’s necessary;
    -run usb_boot.exe;
    - enter the command “run restore.sh” and the recovery process has started.

    If errors arise during the recovery process, either we use a shorter USB cable or you need to plug it into the connector on the back of the computer. We fix the cable problem and try all over again.

    Actually after that we get again a working device. (Impatient and unknowing can finish reading =))

    Now I’ll tell you more about the process of saving / restoring the player’s firmware and its components

    Before going into any serious situations, you need to understand what we are dealing with.
    The firmware and user content in the player is stored in the Samsung NAND-flash memory chip K9G8G08U0A.
    NAND-flash memory chips are generally a very peculiar thing and have their own organization of memory space and the sizes of sectors / blocks, which are not at first familiar to ordinary computer scientists. Let's try to figure it out.

    The smallest addressable unit in this type of memory is a page (a certain analogue of the sector / block of a hard disk). The page itself has, at first glance, a strange size of 528/1056/2112/4224/8448 ... bytes depending on the model. But this is done well-intentioned. NAND-flash memory has a very limited number of write cycles and over time, its individual bits begin to fail. To determine these failures and restore information in the page with bad bits, such an “exotic” size was chosen. The page is essentially divided into two parts. The first part is 512/1024/2048/4096/8192 ... the byte is a multiple of 512 bytes and stores user information, and the remaining part is 16/32/64/128/256 ... the ECC (checksum) of the first part of the page is stored and some other service information.
    Next, the pages are combined into blocks. This is done at the hardware level to speed up the process of erasing information in all pages of a block with one single command. Further, the blocks are physically combined into one silicon crystal. Such crystals in one case can be 1, 2 or 4 and they are selected using the outputs of CS (chip select).

    Now back to our test subject K9G8G08U0A. Its memory organization is as follows: 2048 + 64 bytes per page, 128 pages per block and 4096 blocks per chip.

    To simplify the understanding of the above, I will give a picture from the official datasheet for this chip: Having figured out the

    image

    organization of the memory of the chip, we will consider the components of the firmware and the process of starting the hardware OS

    The firmware consists of the following parts (see * .bin files in the folder with the
    flash driver ): 1) spl (secondary program loader) - the initial bootloader, the nand.bin file in the archive
    2) loader - the main bootloader itself, which loads the OS kernel and memory transfers control to it, the loader.bin file
    3) loader config - bootloader settings, where the location of the OS kernel and resources in the NAND chip and the addresses in RAM where it is all loaded are written in, def_boot.bin
    4) boot image - picture, which is displayed when the OS boots (the dada is the same yellow), the file img_boot.bin
    5) the kernel of the operating MINIOS systems, minios.bin file
    6) OS internal file system with various resources, res.bin file.

    Actually in the same order is the launch of the OS.
    First of all, IPL starts (the loader is wired by the manufacturer into the processor itself). It checks the state of the processor legs, which set the load order and whether the button is pressed. If the button is pressed, then USB download is expected, if not, it is loading from memory. IPL reads the first 8 kilobytes (0-3 pages) in which the SPL code of the bootloader is located into the internal SRAM memory from the NAND-flash memory chip. Checks their correctness by ECC and some other signs, and if everything is fine, transfers control to it. If something went wrong, a similar action is performed with the next 8 kilobytes of NAND-flash memory (4-7 pages).
    After starting, the SPL initializes the registers and peripherals of the processor, configures the SDRAM controller and loads the OS direct loader code (loader.bin) into the RAM at the address indicated at the beginning of 61 and 62 pages.
    Next, the main loader loads the kernel of the operating system into RAM and transfers control to it.
    The question is, why do so many loaders to fence? There is nothing to be done about it, iron limit. IPL can not load more than 8 kilobytes of code, and therefore you have to make a 2-story bootloader.

    From the theoretical foundations we begin to practice.
    Let’s look at how it works, this damned moonshine! ... uh, in the sense of how the utility is designed to download the player via USB and its firmware.
    -fw.bin and usb_boot.bin files are, in no other way, specially written by SPL and Loader;
    -USB_Boot.exe -programs - original management utility spec. by usb_boot.bin loader, Test_jz4740_usb.exe - corrected tronix286 version with the ability to read the contents of NAND-flash memory to a file;
    - all other files * .bin - player firmware components;
    -files Usb_Boot_Driver.inf and Usb_Boot_Driver.sys - drivers for the player in usb-loading mode;
    -files * .cfg - bootloader configuration files for different memory chips (both NAND and SDRAM) and their modes of operation.
    -file restore.sh - a script for uploading firmware to the player.

    The Test_jz4740_usb.exe utility differs from USB_Boot.exe in the presence of two commands (ndump and nreadtofile) intended for reading firmware from the player’s memory.
    The commands that we will need:
    -boot - loading the usb bootloader into the player using the default configuration from the USBBoot.cfg file
    -nerase - ON BLOCK erasing information from the NAND-flash memory chip;
    -nprog - write information from a file to the pages of a NAND-flash memory chip;
    -ndump - read the contents of memory from NAND-flash to a file;
    -fconfig - switch configurations.
    The parameters of each of the commands can be found by running it without parameters.

    We will figure out how to save the original firmware
    I’ll tell you about one huge nuance, about which a bunch of spears were broken and a dozen swords were blunted during a brainstorming session. Download and read the SPL with the USBBoot_nand.cfg configuration, and everything else with the USBBoot_norm.cfg configuration. The use of 2 configs is due to the fact that the recording of the spl-bootloader and everything else happens with different formats of the service area (in terms of usb-boot it is called OOB) and the checksum of the pages. For the SPL loader, the format is used that is wired internally inside the processor, and for everything else, the format chosen by the programmers during the assembly and compilation of the bootloader and OS is used.

    Before starting to save the native firmware, do not forget to delete the files with my firmware from the folder. To merge the firmware, do the following:
    -disconnect the battery from the player, or insert a piece of paper under the contact opening the page;
    - press the button on the player and hold down the button, insert the usb cable and release the button;
    - the computer determines a new device, install drivers for it from the archive;
    -run Test_jz4740_usb.exe;
    - enter the command " boot 0 ", and look at the result of its execution. Something like this should appear: -we switch to the "correct" configuration for reading the SPL with the command " fconfig USBBoot_nand.cfg 0 ", again if everything is in order there should be an inscription " "; -read the SPL and its configuration pages in the nand.bin file with the command " ndump 0 64 0 0 nand.bin ";

    Checking state of No.0 device: Unboot
    Now booting No.0 device: START_ADDR 2000000 81c00000

    Download stage one program and execute at 0x80002000: Pass
    Download stage two program and execute at 0x81c00000: Pass
    Boot success!
    Now configure No.0 device:
    Now checking whether all configure args valid:
    Current device information: CPU is Jz4750
    Crystal work at 12MHz, the CCLK up to 336MHz and PMH_CLK up to 112MHz
    Total SDRAM size is 32 MB, work in 4 bank and 16 bit mode
    Nand page size 2048, ECC offset 3, bad block ID 0, use 1 plane mode
    Configure success!


    Configure success!

    -we switch to the "correct" configuration to read the rest of the firmware with the command " fconfig USBBoot_norm.cfg 0 ", if everything is in order there should be an inscription " Configure success!";
    -we read the loader to the file loader.bin with the command " ndump 128 66 0 0 loader.bin "
    -we read its settings into the file def_boot.bin with the command " ndump 256 1 0 0 def_boot.bin "
    -we read the boot image into the file img_boot.bin with the command " ndump 512 3061 0 0 img_boot.bin "-
    read the OS kernel into the minios.bin file with the command" ndump 8192 8192 0 0 minios.bin "
    read the internal FS with kernel resources into the res.bin file with the command" ndump 32768 32768 0 0 res.

    If desired, all these commands can be written to a file in turn and started with the run command in the same way as the filling process. UPD Which I did and saved to the save.sh file.
    The resulting files are the backup of the native firmware. Now with the firmware of the player you can do anything and are not afraid to get an unusable piece of iron.

    All addresses for recording were obtained from information that displays on the internal uart console of the player’s OS at boot time and experimentally.

    As a result, we get:
    1) SPL is in 0-3 pages;
    2) 61, 62, 63 pages need SPL for subsequent loading;
    3) the main bootloader starts at 128 pages;
    4) its configuration is at 256 pages;
    5) the boot image starts at 512 pages;
    6) the MINIOS core starts at 8192 pages;
    7) internal FS starts 32768 pages;
    8) followed by a user file system with content.

    I think the process of uploading the firmware back to the player is unnecessary, it is similar to saving. If you open notepad (or any other text editor) the restore.sh file, you can see all the process commands with your own eyes. If you wish, you can not completely flash the player, but only change its individual parts.

    Now having a backup of the firmware and knowing how to fill it in, you can try pouring any other firmware into the player. At the moment, I'm trying to compile and write the u-boot loader to it to start Linux.

    UPD !!! An annoying error was found in the Test_jz4740_usb.exe utility! Be sure to download the archive again with the latest version of the utility using the link at the beginning of the post or the utility itself here !
    All old archives were deleted in order to avoid the spread of glitches.

    Also popular now: