4

Goal:

1 - To load a older version of the firmware on the device because it has features the newer version does not.

2 - To set the player up as a multi-boot (U-boot). key press for original OS or my custom compiled linux OS.

Hardware:

mp3 player based on mx23 from Freescale, mmc/SD storage 8GB, USB, 4“ LCD, UART.

I have 3 of the players and as far as I can tell the hardware is the same between the players. (LCD, MMC, UART, etc)

OTP eFuse sets the boot mode as SD_MBR_BOOT—SD Master Boot Record (MBR) mode. They do NOT use Boot Control Block (BCB). (see question)

On one of the players I have soldered to the UART test pads and with a buffer connected to a PC serial port. I will call this the TEST player, and the other 2 that do not have the UART soldered I will call DONOR-1 and DONOR-2.

The TEST player has the newer firmware that I would like to replace with the older firmware. DONOR-1 and DONOR-2 both have an older firmware version.

I also have a firware-update.SB file that is the newer version.

I have 4 unique firmware.SB files all different versions. Two of them contain the feature I want.

What I have done so far:

With a custom compiled linux, I have made an image of the original OS from the mmc using dd. Image is in 3 parts due to 3G limit of fat32. This has been done for all 3 players. I load linux using the HID recovery mode.

I am able to dd the TEST image to the TEST player without any problems.

If I replace any of the SB files with the other 3 the player will not boot. The LCD back light does come on.

If I dd the whole image from the DONORs the player will not boot. The LCD back light will come on.

I have decrypted the recovered SB file from the images with sbtoelf (Rockbox). I have done the same with my image that has u-boot and linux in it as a comparison.

The firmware SB files have 8 sections in them. 3 bootable and 5 clear text.

My SB file has 1 section. Bootable.

I have used ‘arm_disass’ to disassemble the ELF files. My knowledge here is weak, but I dont think that the disassemble program catches when the code switches between 16bit Thumb2 instructions and 32bit ARM instructions...

In short I am not able to get any firmware to boot on the TEST device except the one that originally came from it.

The partition tables does not make sense to me.

fdisk -l

sectors  = 512

TEST

p1* 193406   15859711  7833153   1  FAT12
p2       4     126207    63102  53  OnTrack DM6 Aux
p3  189310     191357     1024   1  FAT12
p4  191358     193405     1024   1  FAT12

DONOR-1 is similar but not exact

The players have a FAT32 partition that is larger that 7GB when it is plugged into a computer. Shows up as a mass storage device. This is where the media lives. Notice the missing blocks.

The firmware includes the MBR_SIGMATEL_ID after the MBR signature (55AA).

MBR and MBR_SIGMATEL_ID of TEST

Working with the TEST player and its good image:

I have removed the MBR_SIGMATEL_ID and there is not change in the way the player boots or does not boot.

  • Moved the boot flag from P1 to P2: Does not boot.
  • Moved the boot flag from P1 to P3: Starts to boot then crashes.
  • Moved the boot flag from P1 to P4: Starts to boot then crashes.
  • Removed the boot flag: Starts to boot then crashes

I am not sure what to do next. Any suggestions?

STMP3780 “Safe Binary” u-boot linux-fslc mx23 imx233 ARMv5

Improve this question
10
  • I would start copying parts of one of the donor's file system to the test one, and seeing when stuff gets wrong. For example, does logically copying the first (bootable) partition working? does copyingg certain files of that partition working? Right now the question seems a bit to broad, I don't think we can come up with an answer without further tinkering.
    – NirIzr
    Oct 19, 2016 at 13:10
  • 1
    In the question you can see that I did copy the cloned image from the DONAR and the extracted SB file to the type 53 partition. The result was the same. I am not sure how to see "where stuff goes wrong". I have captured the debug output from all boot attempts via the duart. The duart contains a lot of noise but I can still see most of it. I am trying to trace the.. logic flow that way.
    – jc__
    Oct 19, 2016 at 13:37
  • When I am using the HID recovery mode and have loaded my custom linux kernel I am able to fdisk the mmc. The partition table does not match up with the data. Example. P1,P3,P4 are identified as FAT12. I cannot mount any of the partitions. If I change any of the partition info, type or boot flag, the device will not boot. When the device is normal and plugged into a PC a FAT32 mass storage device can be mounted on the host PC.
    – jc__
    Oct 19, 2016 at 13:41
  • JTAG is not available. I am attempting to match up the debug output to the strings in the BIN and ELF files to see what section of code the boot crashes on. Using objdump, strings, arm_disass (rockbox), sbtoelf (rockbox).
    – jc__
    Oct 19, 2016 at 13:49
  • What other information can I provide here? I have done much more that what is noted here.
    – jc__
    Oct 19, 2016 at 13:50

1 Answer 1

Reset to default
1

What I found out about the firmware and hardware on these identical systems.

They are in fact not identical. There is a hardware difference in the LCD used. This is the reason the older firmware did not work.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.