fpdoom
fpdoom copied to clipboard
Samsung GT-E1272 `LIBUSB_ERROR_PIPE`
This error happens with the run.bat script from the libc_server release
BSL_REP_VER: "SPRD3\0"
BSL_REP_VER: "Custom FDL1: CHIP ID = 0x65300000\0"
!!! entry1
malloc heap: 3723100 bytes
scan_firmware: 461ms
keymap = 0x300cbf18
pinmap = 0x300cbf98
chip_id: num = 0x65300000
chip_id: ver = 0x90001
chip_id: adi = 0x11300004
usb_recv failed : LIBUSB_ERROR_PIPE
When running that script again, another error raises:
libusb_get_config_descriptor failed : LIBUSB_ERROR_NOT_FOUND
It's an old SC6530 chip, the oldest I could find was an SC6530C from another old Samsung phone (B310E). So I can't support this as the original SC6530 is very hard to find these days.
But I found it on sale, so I'll write later when I receive it.
When running that script again, another error raises:
libusb_get_config_descriptor failed : LIBUSB_ERROR_NOT_FOUND
If you want to run the script again, then you need to turn off the phone (since it is hang somewhere) by removing the battery and disconnecting it from the USB cable. So the second error is normal under the circumstances.
I received the GT-E1272, but it uses the new SC6531E (aka 6562) chip. It looks like this model was produced with different versions of the chip. So try to dump the firmware from yours, and I’ll try to see the differences.
./spd_dump --wait 300 \
fdl nor_fdl1.bin 0x40004000 \
read_mem 0 128K bootloader.bin \
read_flash 0x80000003 0 4M dump.bin
Ok, here's the firmware. e1272.zip
I saw from the new readme that the boot key for your E1272 is 2, while for my E1272 its the OK (center) button. Many tutorials for this phone instruct to press the OK button, so there is definitely some kind of "new version" of this ~~piece of plastic~~ device.
The bootloader is the same size as the SC6530С (0xdb48). The flash is actually larger than 4MB, probably 8MB. But the most important code is in the first part. I think the problem might be the weird RAM size (like 3MB or 6MB), I'll make a custom build of Doom with more prints to make it clearer where the error occurs.
I saw from the new readme that the boot key for your E1272 is 2, while for my E1272 its the OK (center) button. Many tutorials for this phone instruct to press the OK button, so there is definitely some kind of "new version" of this ~piece of plastic~ device.
Since it is on a newer chip, everything may be different, the firmware is incompatible. The boot key is simply the key in the first column and first row. Where the rows and columns are the tracks on the printed circuit board. Perhaps I bought a fake E1272.
Here is a video of the phone that I got.
Here is a video of the phone that I got.
Your keypad looks a little bit different than mine. Look closely to the voicemail (1), mute (*) and change SIM card (#) buttons. The English font on the keypad looks different too, you either have actually gotten a fake one or Samsung decided to also modify the keypad (or it's a "restored" phone with an unoriginal keypad, which is unlikely).
If you need it, the full compatible with my phone (I have flashed it) firmware is available here.
Yes, the D-pad looks better on your phone. On the one I have, it's difficult to hit the directional buttons.
Try to run Doom from fpdoom_prints.zip from the Releases.
Here's what it should print normally:
BSL_REP_VER: "SPRD3\0"
BSL_REP_VER: "Custom FDL1: CHIP ID = 0x65620001\0"
!!! entry1
malloc heap: 3723072 bytes
scan_firmware: 315ms
keymap = 0x10084b10
pinmap = 0x10080eec
chip_id: num = 0x65620001
chip_id: ver = 0xa0002
chip_id: ahb = 0x609
chip_id: adi = 0x1161a000
pin_init
lcm_init
lcm_init 1
lcm_init 2
lcm_init 3
lcm_init 4
LCD: clk_rate = 104000000
LCD: id = 0x009306
lcd_init
lcd_appinit
lcdc_init
keypad_init
keytrn_init
sys_init end
!!! entry2
DOOM Shareware Startup - v1.10
Since there is no "LCD: clk_rate = " in your log, the error is somewhere in the pin_init or lcm_init, so it's not a RAM size issue.
Here are the logs:
Waiting for connection (300s)
BSL_REP_VER: "SPRD3\0"
BSL_REP_VER: "Custom FDL1: CHIP ID = 0x65300000\0"
!!! entry1
malloc heap: 3723072 bytes
scan_firmware: 461ms
keymap = 0x300cbf18
pinmap = 0x300cbf98
chip_id: num = 0x65300000
chip_id: ver = 0x90001
chip_id: adi = 0x11300004
pin_init
lcm_init
lcm_init 1
lcm_init 2
lcm_init 3
usb_recv failed : LIBUSB_ERROR_PIPE
So this is a mysterious part, that I copied it from the original firmware:
if (!is_whtled_on()) lcm_wait(32, 0);
It must be a soft reset of the LCM (LCD Manager).
The LCD detection doesn't work if I disable this line:
BSL_REP_VER: "SPRD3\0"
BSL_REP_VER: "Custom FDL1: CHIP ID = 0x65620001\0"
!!! entry1
malloc heap: 3723072 bytes
scan_firmware: 306ms
keymap = 0x10084b10
pinmap = 0x10080eec
chip_id: num = 0x65620001
chip_id: ver = 0xa0002
chip_id: ahb = 0x609
chip_id: adi = 0x1161a000
pin_init
lcm_init
lcm_init 1
lcm_init 2
lcm_init 3
lcm_init 4
LCD: clk_rate = 104000000
LCD: id = 0x040404
!!! unknown LCD
!!! exit(1)
Doesn't work even if I put a 5 second sleep here.
I added fpdoom_prints2.zip for you to test, but I don't think it will help you.
I'll try to find this part in your phone's firmware to see if there are any differences.
Same error as yours, just different ids.
Waiting for connection (300s)
BSL_REP_VER: "SPRD3\0"
BSL_REP_VER: "Custom FDL1: CHIP ID = 0x65300000\0"
!!! entry1
malloc heap: 3723072 bytes
scan_firmware: 462ms
keymap = 0x300cbf18
pinmap = 0x300cbf98
chip_id: num = 0x65300000
chip_id: ver = 0x90001
chip_id: adi = 0x11300004
pin_init
lcm_init
lcm_init 1
lcm_init 2
lcm_init 3
lcm_init 4
LCD: clk_rate = 104000000
LCD: id = 0x008000
!!! unknown LCD
!!! exit(1)
usb_recv failed : LIBUSB_ERROR_PIPE
Now try fpdoom_test1.zip, it looks like is_whtled_on() shouldn't be called for SC6530.
BSL_REP_VER: "SPRD3\0"
BSL_REP_VER: "Custom FDL1: CHIP ID = 0x65300000\0"
!!! entry1
malloc heap: 3723072 bytes
scan_firmware: 461ms
keymap = 0x300cbf18
pinmap = 0x300cbf98
chip_id: num = 0x65300000
chip_id: ver = 0x90001
chip_id: adi = 0x11300004
_chip = 2
lcm_reset
usb_recv failed : LIBUSB_ERROR_PIPE
I see, is_whtled_on() is still being called, but it doesn't seem to be causing the hang.
I added fpdoom_test2.zip, but that probably won't help, it appears some necessary initialization is missing.
Or maybe there's not enough power for the LCD.
Try adding the --charger 1 option. Example:
cd workdir && ..\libc_server -- --bright 50 --charge 1 --rotate 3 doom
Also try holding down the boot key, insert the battery and connect to USB (hold the boot key until you connect the cable).
I added
fpdoom_test2.zip, but that probably won't help, it appears some necessary initialization is missing.Or maybe there's not enough power for the LCD.
Try adding the
--charger 1option. Example:cd workdir && ..\libc_server -- --bright 50 --charge 1 --rotate 3 doom
Neither of those things helped :(
Also try holding down the boot key, insert the battery and connect to USB (hold the boot key until you connect the cable).
I actually have been doing that for every time I ran this.
Does this phone boot into its regular OS? Because it's strange that it halts when the LCD is turned on, as if the contacts on the LCD board have shorted out.
Does this phone boot into its regular OS? Because it's strange that it halts when the LCD is turned on, as if the contacts on the LCD board have shorted out.
Yes it does, by pressing the power key after exiting the download mode.
Does the screen backlight (or flashlight) turn on when running the Doom port?
There seems to be some crazy way to connect a display to an ADC (Analog-to-Digital Converter), that I've never encountered before. Perhaps this method is used in this case. But I can’t do this without a device, it requires a lot of debugging.
Try fpdoom_test3.zip with these settings:
cd workdir && ..\libc_server -- --bright 50 --lcd 0x5cb1f0 --rotate 3 doom
Since the ADC is probably used only for reading from the LCD, we’ll try to do it without detection, this firmware only supports one LCD model.
Sorry for not replying earlier.
Does the screen backlight (or flashlight) turn on when running the Doom port?
Nope.
Try
fpdoom_test3.zipwith these settings:
Still the same error...
BSL_REP_VER: "SPRD3\0"
BSL_REP_VER: "Custom FDL1: CHIP ID = 0x65300000\0"
!!! entry1
malloc heap: 3723072 bytes
scan_firmware: 463ms
keymap = 0x300cbf18
pinmap = 0x300cbf98
chip_id: num = 0x65300000
chip_id: ver = 0x90001
chip_id: adi = 0x11300004
LCD: clk_rate = 104000000
LCD: id = 0x5cb1f0
usb_recv failed : LIBUSB_ERROR_PIPE
Will adding --gpio_init change anything?
cd workdir && ..\libc_server -- --bright 50 --gpio_init --lcd 0x5cb1f0 --rotate 3 doom
Will adding
--gpio_initchange anything?
BSL_REP_VER: "SPRD3\0"
BSL_REP_VER: "Custom FDL1: CHIP ID = 0x65300000\0"
!!! entry1
malloc heap: 3723072 bytes
scan_firmware: 461ms
keymap = 0x300cbf18
pinmap = 0x300cbf98
chip_id: num = 0x65300000
chip_id: ver = 0x90001
chip_id: adi = 0x11300004
usb_recv failed : LIBUSB_ERROR_PIPE
Try fpdoom_test4.zip and I think we'll give up there. You should see "adc_init", "adc_init ok" in the log.
This adds ADC initialization, but I don't think that will help.
static void adc_init(void) {
#if CHIP == 2 || CHIP == 3
int b = ANA_REG_BASE + 0x680;
adi_write(ANA_REG_BASE + 0x40, 1);
adi_write(ANA_REG_BASE + 0x40, 2);
adi_write(ANA_REG_BASE + 0xe0, 0x20);
adi_write(ANA_REG_BASE + 0xe0, 0x10);
adi_write(ANA_REG_BASE + 0xe4, 0x10);
adi_write(ANA_REG_BASE + 0xa0, 8);
DELAY(10)
adi_write(ANA_REG_BASE + 0xb0, 8);
adi_write(b, adi_read(b) | 1);
adi_write(b + 0x48, 0xe0);
adi_write(b + 0x34, adi_read(b + 0x34) | 0x40);
adi_write(b + 0x2c, adi_read(b + 0x2c) | 0x40);
adi_write(b + 0x30, adi_read(b + 0x30) | 0x40);
adi_write(b + 0x28, adi_read(b + 0x28) | 0x40);
adi_write(b + 0x2c, adi_read(b + 0x2c) & ~0xf);
adi_write(b + 0x2c, adi_read(b + 0x2c) | 2);
adi_write(b + 0x34, adi_read(b + 0x34) & ~0xf);
adi_write(b + 0x34, adi_read(b + 0x34) | 3);
#endif
}
Try
fpdoom_test4.zipand I think we'll give up there. You should see "adc_init", "adc_init ok" in the log.
There is that in the logs, but it still doesn't start. The screen backlight doesn't even turn on…
BSL_REP_VER: "SPRD3\0"
BSL_REP_VER: "Custom FDL1: CHIP ID = 0x65300000\0"
!!! entry1
malloc heap: 3723072 bytes
scan_firmware: 461ms
keymap = 0x300cbf18
pinmap = 0x300cbf98
chip_id: num = 0x65300000
chip_id: ver = 0x90001
chip_id: adi = 0x11300004
adc_init
adc_init ok
LCD: clk_rate = 104000000
LCD: id = 0x5cb1f0
usb_recv failed : LIBUSB_ERROR_PIPE
It could be a watchdog timer, but it's not clear why it suddenly turned on. If you successfully dumped the firmware, it means it was not enabled during dumping.
What OS are you using? Can you rebuild the game binary yourself?
What OS are you using? Can you rebuild the game binary yourself?
Mostly I use Windows 10, but I have Arch Linux dual-booted.
Try to install ARM cross compiler or Android NDK and compile this.
NDK example:
NDK=$HOME/android-ndk-r25c
TOOLCHAIN=$NDK/toolchains/llvm/prebuilt/linux-x86_64/bin/llvm
CLANG=$NDK/toolchains/llvm/prebuilt/linux-x86_64/bin/armv7a-linux-androideabi21-clang
make all TOOLCHAIN=$TOOLCHAIN CC=$CLANG
cross GCC example:
TOOLCHAIN=/usr/bin/arm-linux-gnueabi
make all TOOLCHAIN="$TOOLCHAIN" LD_EXTRA="-Wl,--no-dynamic-linker"
Use fptest.bin instead of fpdoom.bin, this is a simple display and keypad test.
Put this code in fpdoom/syscode.c to test the timer:
LCM_CR(0x10) = 1;
LCM_CR(0x14) = 0xa50100;
+ DBG_LOG("sys_timer = %u\n", sys_timer_ms());
+ sys_wait_ms(1); DBG_LOG("1ms delay ok\n");
+ sys_wait_ms(1000); DBG_LOG("1s delay ok\n");
+ sys_wait_ms(3000); DBG_LOG("3s delay ok\n");
if (IS_SC6530 || !is_whtled_on()) lcm_reset(32, 0);