Reset options fail to reset; expected ID 0x1610, got 1651

Picked up a Mod Duo from @Skydiver a few months ago, love it. Last week at the beginning of a gig my Mod Duo crashed and wouldn’t reboot; thankfully it’s designed to be in bypass mode when it’s dead. I have gone through all of the steps outlined in Troubleshooting Reinstall - MOD Wiki, starting with left buttons press/power-on and including bootloader/factory reset/USB install. Nothing unbricks the unit.

It’s clear that my Ubuntu box is communicating with the Duo, since if (after hitting the FEL button and powering on) I forget to plug the USB in to the computer before running a script, the script tells me that. Also when I installed the latest image RAW file it seemed to run to completion.

However, once I’ve completed that step, when I try to install the bootloader via any method it kicks out of the script (right after starting stage 2) with the error noted in the subject line:
Expected ID 0x1610, got 1651

Not sure how I would tell you to reproduce this other than using my unit. Is this a hardware addressing issue? And is it something I can fix by SSHing into the unit, or do I have to send it back? And if I send it back, am I sending it to Dean or to Mod HQ?

Thanks!
Joshua

I tried to SSH into 192.168.51.1 to see what I could see, but it kept timing out. So I decided to see if going through the factory reset options again would do anything (definition of insanity, I know), but this time it told me that FEL access was denied to the unit even though I had pressed in the FEL button prior to powering on and waited two seconds before releasing and connecting to USB. That would explain why I couldn’t SSH in, but begs the question of WTH happened to FEL.

@falkTX @ricardocrudo you guys seem to be the reset/recovery/ssh masters; any advice?

The wiki needs update for the latest batch of Duo units, as the steps mentioned there do not work anymore.
I will be handling that in the next few days…

In mean time, the procedure for the new units is to enable FEL mode (power on the unit while pressing the tiny button in the back), and then push a special payload via USB to boot into recovery mode.
I have temporarily uploaded the script and binaries here https://nextcloud.falktx.com/s/K3HANSqRfXFatKM
(there is a single script inside and a few binaries)

after this you can install a software image as usual.
the new units need minimum 1.7

1 Like

@falkTX that seemed to do something–it ran through the packages and told me that it was “all done” after running duo2019-fel-boot-restore.sh–but what’s the next step? What is the expected behavior after running that script?

Simply power cycling doesn’t get me to a restore screen (at least I don’t think; there are no images in the wiki or elsewhere online that show what the restore screen actually looks like but I presume I’d know it if I saw it), and pressing the left-side buttons while powering on doesn’t do anything.

I downloaded the 1.8 release, but there’s no way to manually install it since it’s not getting past the logo screen and doesn’t show up as an external volume on my linux box.

I revisited the bootfixes from the Troubleshooting wiki, but you mentioned everything there is out of date (that didn’t stop me from trying, and I still got the error from the subject line).

So… what’s my next move?

it is supposed to start the unit in restore mode, the same where you can manually install updates on.
But I see maybe I jumped the gun thinking you had one of the new units…
Does your Duo have “MOD Duo” written/engraved above the screens?

It does not have the engraving, so I guess it’s not one of the newer units (wasn’t sure how you were defining “new” in your post so I didn’t catch that). Definitely pre-DuoX release. I’m guessing there’s a serial number under the velcro I’ve applied to the back, do you need that?

no, no need for the serial.

I have all the different Duo unit types with me here, so I will revisit the wiki troubleshooting section and ensure what we have there works for all of them.
Not much time for this today though, probably tomorrow.

Much appreciated, cheers!

If it turns out my unit is hopelessly borked and I need to be one of the first to try the at-home logic board upgrades, just let me know… :grinning:

hey @bassandboy I have been updating the wiki and just generated a new factory reset image, replacing the old http://download.moddevices.com/releases/factory/modduo-latest-factory-image.raw link (it used to include v1.5.0, now updated to v1.7.3)
the link remains the same, but its contents are now updated.

can you redownload and try again the step that uses this file?
thanks a lot!

2 Likes

@falkTX still no good. I’m getting kicked out again by the “expected ID 0x1610 got 1651” error. Maybe a boot-fel-restore.sh type install would work better? Or perhaps it’s an issue with the bootfix script? Here’s the full traceback:

    $ sudo ./bootfix -w ./modduo-latest-factory-image.raw 
    Speed = 12 Mbps`
    Start stage 1
    URB 5
    AWUSBFEX soc=001651 (A20) fw=01 mode=fel type=D len=08 addr=7e00
    Detected A20 (ID 0x1651)
    URB 14
    AWUSBFEX soc=001651 (A20) fw=01 mode=fel type=D len=08 addr=7e00
    URB 23
    URB 32
    AWUSBFEX soc=001651 (A20) fw=01 mode=fel type=D len=08 addr=7e00
    URB 41
    URB 50
    AWUSBFEX soc=001651 (A20) fw=01 mode=fel type=D len=08 addr=7e00
    URB 63
    URB 72
    URB 77
    Sending sun7i/fes_1-1.fex...done
    URB 87
    URB 96
    URB 105
    URB 114
    Sending sun7i/fes_1-2.fex...done
    URB 120
    URB 129
    URB 138
    1024MB RAM detected
    URB 147
    URB 153
    URB 165
    URB 174
    Sending sun7i/fes.fex...done
    URB 192
    Sending sun7i/fes_2.fex...done
    URB 198
    End of stage 1
    Re-opening.done
    Speed = 12 Mbps
    Start stage 2
    URB 5
    AWUSBFEX soc=001651 (A20) fw=01 mode=fel type=D len=08 addr=7e00
    Expected ID 0x1610, got 1651

Something is off here…
There are a few things we can try.

Booting over USB is the best choice for now, just to see if we get a storage device.

I am yet to test this on all devices, but it should work on yours.
So the steps:

  • Click and hold down the FEL button on the back of the MOD Duo (in tiny hole), while you power it on.
  • Hold it for 2 seconds, then release
  • Connect the MOD Duo to your computer via USB cable
  • Download http://download.moddevices.com/releases/modduo/tools/mod-boot-fel-restore-v2.tar.gz and extract it
  • Open a terminal and ‘cd’ to the directory where mod-boot-fel-restore.zip was extracted, ie:
    cd ~/Downloads/mod-boot-fel-restore/

(If not you’re running 64bit, install sunxi-tools from your Linux distribution, and copy /usr/bin/sunxi-fel to the current directory, overriding the existing file there.)

Continuing:

  • Run: MARS=1 ./boot-fel-restore.sh
  • Wait for around 2 minutes, and the MOD Duo will boot into recovery mode.

If we are able to get the recovery mode this way, then great :slight_smile:
If it doesn’t work, try the same steps again but remove MARS=1 when running the script.

Let me know how it goes.

Alright, I followed those instructions both with and without MARS=1. Neither booted the unit into recovery mode. Traceback below is identical in each case, except for the value of mars. What’s next? :sweat_smile:

$ sudo ./boot-fel-restore.sh 
:::: writing u-boot-spl.bin
:::: running u-boot-spl.bin
:::: writing u-boot.bin
:::: writing ramboot.scr
:::: writing script.bin (mars = 1, emmc = 0)
:::: writing uImage
100% [================================================] 19627 kB,  315.7 kB/s 
:::: running u-boot.bin
:::: all done

@Skydiver @falkTX since this is looking more and more hopeless, what’s my warranty situation for an April 24 purchase? Is the solution just a swapped unit? Or is it an H9? :rofl::sob:

@bassandboy
Sorry to see you are having issues with your unit.

At Green Elephant Studio we offer a 90 day return policy and unfortunately we are outside that window now and will need to work with MOD. The unit is still under the manufacturers warranty but I hope that we can work out the issue remotely and I believe that we should be able to.

@falkTX Any ideas on how to move forward?

sorry taking longer than usual to reply…

only possible next step without a recall that I see is to try the livesuit approach.
It is a bit advanced though.
instructions on how to get it running are here https://linux-sunxi.org/LiveSuite
(it is basically an alternative from the previous bootfix method, but one that comes from the board manufacturer so in theory it might work better)

we need to deploy this custom image: http://download.moddevices.com/releases/modduo/tools/modduo_livesuit_20180618.img

if that works, then @bassandboy will get a restore mode back, ready to install any MOD OS image again.
if that still does not work, we need to replace the coreboard

EDIT: just tested this myself. after the initial deploy via LiveSuit and the unit rebooting into self-mode, we should replug the unit power supply. very hard to know why, since we are not in control of this application, but okay, minor step when reinstalling from scratch.

1 Like

The time difference between Portugal and Hawaii is perfect for ensuring that I get your updates right before I have to go to work and need to wait all day to try them out!

Unfortunately, this latest solution isn’t working because make isn’t working (the script is balking when warnings are treated as errors). This is of course a compiler issue, but when I search through all the files I can’t find the CFLAG that’s causing the warning-error, so I can’t get even copy the kernel or install the module or get to the good stuff.

I’m not a linux noob, but this is ridiculous just to reboot a f**king pedal. I’ll include the traceback, but I really think this is the point where either I send the device back to MOD HQ or you send me a new coreboard to install (whichever is protocol).

make -C /lib/modules/4.18.0-20-generic/build SUBDIRS=/home/jahschwa/sunxi-livesuite/awusb modules
make[1]: Entering directory '/usr/src/linux-headers-4.18.0-20-generic'
  CC [M]  /home/jahschwa/sunxi-livesuite/awusb/awusb.o
/home/jahschwa/sunxi-livesuite/awusb/awusb.c: In function ‘write_aw’:
/home/jahschwa/sunxi-livesuite/awusb/awusb.c:376:8: error: implicit declaration of function ‘signal_pending’; did you mean ‘timer_pending’? [-Werror=implicit-function-declaration]
    if (signal_pending(current)) {
        ^~~~~~~~~~~~~~
        timer_pending
cc1: some warnings being treated as errors
scripts/Makefile.build:330: recipe for target '/home/jahschwa/sunxi-livesuite/awusb/awusb.o' failed
make[2]: *** [/home/jahschwa/sunxi-livesuite/awusb/awusb.o] Error 1
Makefile:1534: recipe for target '_module_/home/jahschwa/sunxi-livesuite/awusb' failed
make[1]: *** [_module_/home/jahschwa/sunxi-livesuite/awusb] Error 2
make[1]: Leaving directory '/usr/src/linux-headers-4.18.0-20-generic'
Makefile:6: recipe for target 'default' failed
make: *** [default] Error 2

Clearly frustration ruling my manners; something in the process of attempting to get ‘make’ to run also caused a kernel panic so the nerves are a bit raw. Will attempt to enlist the prowess of a better admin than I—seems a pity to at least not try the livesuit image file.

Sorry for that, the project is not ours so there is not much we can do in regards to that tool.
I had the same issue myself, there is already a PR which fixes the build.
Only needs this small change https://github.com/linux-sunxi/sunxi-livesuite/pull/5/commits/4dac537aea6feece17834e5e81c0f27b305042fd

I can understand the frustration. It is the first time we see this specific issue, so we were not prepared…
Perhaps one final attempt? Or if you really do want to go any further, all fine, just let me know and I will ping the team to contact you for replacing the coreboard.

@falkTX I’m amazed that the fix was committed two years ago and hasn’t been incorporated by the SunXi devs. Mind boggling.

I was able, at long last, to get LiveSuite up and running. I was really, REALLY hopeful having gotten over that hurdle, but it’s still not working. LiveSuite detects that I’ve plugged in a device, and starts working, but then it gives me the following messages in the GUI:

Failed to flash firmware: Waiting for Fes Device Timeout...
and then
No device available!

Is my FEL button broken? Or something about the reset process? My assumption based on the tracebacks I’ve posted above and the one below in this post has been that the FEL button works, and that the system simply can’t be accessed for some reason.

At this point it simply seems like fixing it here via software or firmware is never going to work. Please advise.

$ sudo ./LiveSuit.sh
Starting x86-64/LiveSuit.

library file path: /home/jahschwa/sunxi-livesuite/x86-64/plgvector.dll
library file path: /home/jahschwa/sunxi-livesuite/x86-64/LangPlg.dll
LoadFile 24
Open 274: Language file format is UTF-8
library file path: /home/jahschwa/sunxi-livesuite/x86-64/LiveProc.Plg
library file path: /home/jahschwa/sunxi-livesuite/x86-64/plgvector.dll
library file path: /home/jahschwa/sunxi-livesuite/x86-64/luaeFex.dll
Register./luaBase.dll l_RegAllFun Sucess!
Register./luaeFex.dll l_RegAllFun Sucess!
Register./luadec.dll l_RegAllFun Sucess!
IMAGEWTY
ItemTableSize = 1048576
Closing image now! 

Clos image OK! 

Register./luaBase.dll l_RegAllFun Sucess!
Register./luaeFex.dll l_RegAllFun Sucess!
Register./luadec.dll l_RegAllFun Sucess!
IMAGEWTY
ItemTableSize = 1048576
Closing image now! 

Clos image OK! 

Dev Plugin The Device Path is: /dev/aw_efex0
Register./luaBase.dll l_RegAllFun Sucess!
Register./luaeFex.dll l_RegAllFun Sucess!
Register./luadec.dll l_RegAllFun Sucess!
IMAGEWTY
ItemTableSize = 1048576
Closing image now! 

Clos image OK! 

Register./luaBase.dll l_RegAllFun Sucess!
Register./luaeFex.dll l_RegAllFun Sucess!
Register./luadec.dll l_RegAllFun Sucess!
IMAGEWTY
ItemTableSize = 1048576
Closing image now! 

Clos image OK! 

[Tl_Msg]Init : imgFilePath=/home/jahschwa/Downloads/modduo_livesuit_20180618.img, imgLen=[0, 21838848], workMode=8

IMAGEWTY
ItemTableSize = 1048576
./buffer.cpp, pBuffer = 0x7f5c5820de64, nLen = 16380, crc32 = 1913822737[Tl_Msg]Down index[1] start

[Tl_Msg]partName=boot, pktSubType=BOOTFS_FEX000000, verifyFile=VBOOTFS_FEX00000

[Tl_Msg]partAddrHigInSec=0x0, partAddrLowInSec=0x8000, partSzHigInSec=0x0, partSzLowInSec=0x10000

[Tl_Msg]isEncrypt=false, toVerify=true

[Tl_Msg]Down index[1] end

[Tl_Msg]Down number is 1

[Tl_Msg]sec[platform]

[Tl_Msg]sec[card2_boot_para]

0x7f5c5820de60, 541, 4, =40x7f5c5820de60, 540, 2, =2[Tl_Msg]sec[card_boot]

[Tl_Msg]sec[target]

[Tl_Msg]sec[dram_para]

[Tl_Msg]sec[DllInfo]

[Tl_Msg]sec[uart_para]

[Tl_Msg][platform]

[Tl_Msg]eraseflag           = 0x0

[Tl_Msg]

[Tl_Msg][card2_boot_para]

[Tl_Msg]sdc_clk             = port:PC07<3><1><default><default>

[Tl_Msg]card_line           = 0x4

[Tl_Msg]sdc_d0              = port:PC08<3><1><default><default>

[Tl_Msg]card_ctrl           = 0x2

[Tl_Msg]sdc_cmd             = port:PC06<3><1><default><default>

[Tl_Msg]sdc_d2              = port:PC10<3><1><default><default>

[Tl_Msg]sdc_d3              = port:PC11<3><1><default><default>

[Tl_Msg]card_high_speed     = 0x1

[Tl_Msg]sdc_d1              = port:PC09<3><1><default><default>

[Tl_Msg]

[Tl_Msg][card_boot]

[Tl_Msg]logical_start       = 0xa000

[Tl_Msg]

[Tl_Msg][target]

[Tl_Msg]storage_type        = 0xffffffffffffffff

[Tl_Msg]

[Tl_Msg][dram_para]

[Tl_Msg]dram_baseaddr       = 0x40000000

[Tl_Msg]dram_chip_density   = 0x2000

[Tl_Msg]dram_size           = 0x400

[Tl_Msg]dram_rank_num       = 0x1

[Tl_Msg]dram_io_width       = 0x10

[Tl_Msg]dram_tpr0           = 0x42d899b7

[Tl_Msg]dram_cas            = 0x9

[Tl_Msg]dram_odt_en         = 0x0

[Tl_Msg]dram_tpr1           = 0xa090

[Tl_Msg]dram_zq             = 0x7f

[Tl_Msg]dram_bus_width      = 0x20

[Tl_Msg]dram_tpr4           = 0x1

[Tl_Msg]dram_emr3           = 0x0

[Tl_Msg]dram_clk            = 0x1b0

[Tl_Msg]dram_emr2           = 0x10

[Tl_Msg]dram_emr1           = 0x4

[Tl_Msg]dram_tpr5           = 0x0

[Tl_Msg]dram_tpr3           = 0x0

[Tl_Msg]dram_type           = 0x3

[Tl_Msg]dram_tpr2           = 0x22a00

[Tl_Msg]

[Tl_Msg][DllInfo]

[Tl_Msg]

[Tl_Msg][uart_para]

[Tl_Msg]uart_debug_rx       = port:PB23<2><1><default><default>

[Tl_Msg]uart_debug_port     = 0x0

[Tl_Msg]uart_debug_tx       = port:PB22<2><1><default><default>

[Tl_Msg]

[Tl_Msg]Init end

[Tl_Msg]fel in: dev[/dev/aw_efex0]

[Tl_Msg]platform id checked OK

[Tl_Msg]To down sys para

[Tl_Msg]To down and Run fes1-1

[Tl_Msg]To clear fes aide log

[Tl_Msg]To down and Run fes1-2

[Tl_Msg]To clear fes aide log

[Tl_Msg]OK test fel Down and Up in len=8192

[Tl_Msg]OK to test dram

[Tl_Msg]Update dram size to 1024MBytes

[Tl_Msg]nMsgRet=0

[Tl_Msg]To down fes2_1

[Tl_Msg]To down fes2_2

[Tl_Msg]To clear fes aide log

[Tl_Msg]not hasRetLog

[Tl_Msg]Fel end

Fel Thread Finished!
[Tl_Msg]Exit called

Closing image now! 

Clos image OK!