Hmm. Can you please try removing the ModemManager package from your PC and power ON the board again?
sudo apt-get purge modemmanager
Hmm. Can you please try removing the ModemManager package from your PC and power ON the board again?
sudo apt-get purge modemmanager
I did it. However, the behavior is that same.
This is the dmesg log
[ 117.155660] usb 7-1: new full-speed USB device number 2 using uhci_hcd
[ 117.307862] usb 7-1: New USB device found, idVendor=12d1, idProduct=3609, bcdDevice= 0.00
[ 117.307869] usb 7-1: New USB device strings: Mfr=1, Product=4, SerialNumber=0
[ 117.307873] usb 7-1: Product: \xffffffe3\xffffff84\xffffffb0㌲㔴㜶㤸
[ 117.307877] usb 7-1: Manufacturer: 䕇䕎䥎
Regards,
Artur
This cannot possibly work. hisi-idt.py must be directed to use the device node that appears when you connect the micro-B socket on the main board to your PC (the one that disappears again after 90 seconds if you fail to launch hisi-idt.py quickly enough).
So yes I do think so too. But I was trying to somehow overcome the issue so the only thing I could see after so much work, was the /dev/ttyUSB0 provided using the UART.
I don’t know how to overcome this issue and get the bord working.
Regards,
Artur
[ 117.155660] usb 7-1: new full-speed USB device number 2 using uhci_hcd
[ 117.307862] usb 7-1: New USB device found, idVendor=12d1, idProduct=3609, bcdDevice= 0.00
[ 117.307869] usb 7-1: New USB device strings: Mfr=1, Product=4, SerialNumber=0
[ 117.307873] usb 7-1: Product: \xffffffe3\xffffff84\xffffffb0㌲㔴㜶㤸
[ 117.307877] usb 7-1: Manufacturer: 䕇䕎䥎
From your dmesg log, it looks like the USB device is recognized but the modem port is not detected. I would suggest you to install gsm-utils:
sudo apt-get install gsm-utils
following your suggestion, I have installed gsm-utils.
But still the result is the same
Are you sure that the required USB packages are installed on your PC? Like usbserial
? Also, can you please try the following workaround?
sudo modprobe usbserial vendor=0x12d1 product=0x3609
Likewise what distro are you running on the PC and have you compiled a custom kernel?
I did this and now I can see ttyUSB1 through usb.
This is the dmesg log
[24671.417241] usb 7-1: new full-speed USB device number 14 using uhci_hcd
[24671.572403] usb 7-1: New USB device found, idVendor=12d1, idProduct=3609, bcdDevice= 0.00
[24671.572410] usb 7-1: New USB device strings: Mfr=1, Product=4, SerialNumber=0
[24671.572414] usb 7-1: Product: \xffffffe3\xffffff84\xffffffb0㌲㔴㜶㤸
[24671.572417] usb 7-1: Manufacturer: 䕇䕎䥎
[24671.574575] usbserial_generic 7-1:1.0: The “generic” usb-serial driver is only for testing and one-off prototypes.
[24671.574579] usbserial_generic 7-1:1.0: Tell linux-usb@vger.kernel.org to add your device to a proper driver.
[24671.574584] usbserial_generic 7-1:1.0: generic converter detected
[24671.574974] usb 7-1: generic converter now attached to ttyUSB1
Using this link you have provided I started the recovery process.
But there are issues.
sudo python hisi-idt.py -d /dev/ttyUSB1 --img1 recovery.bin
±---------------------+
(’ Serial: ‘, ‘/dev/ttyUSB1’)
(’ Image1: ‘, ‘recovery.bin’)
(’ Image2: ', ‘’)
±---------------------+
Traceback (most recent call last):
File “hisi-idt.py”, line 272, in
main(sys.argv[1:])
File “hisi-idt.py”, line 269, in main
burnboot(‘hi3716cv200’, dev, img1, img2)
File “hisi-idt.py”, line 200, in burnboot
downloader = bootdownload(chiptype, serialport)
File “hisi-idt.py”, line 76, in init
self.s = serial.Serial(port=serialport, baudrate=115200, timeout=1)
File “/usr/lib/python2.7/dist-packages/serial/serialutil.py”, line 180, in init
self.open()
File “/usr/lib/python2.7/dist-packages/serial/serialposix.py”, line 311, in open
self._update_dtr_state()
File “/usr/lib/python2.7/dist-packages/serial/serialposix.py”, line 605, in _update_dtr_state
fcntl.ioctl(self.fd, TIOCMBIS, TIOCM_DTR_str)
IOError: [Errno 22] Invalid argument
Exception AttributeError: “‘bootdownload’ object has no attribute ‘s’” in <bound method bootdownload.del of <main.bootdownload object at 0x7f5aa61795d0>> ignored
So I have read on some comments on the web that this script works only with Python 2.7
So I check my Python version is Python 2.7.12.
Hi @arturp,
As spotted by @danielt, the USB driver used by the HiKey is option
and is selected using CONFIG_USB_SERIAL_OPTION
Kconfig symbol. By default most of the distros include it as a loadable module and it gets loaded during boot. But in your case, seems like this module is not properly loaded. Can you please confirm this?
$ lsmod | grep option
This should show the presence of the module. If nothing is displayed then you might want to rebuild your PC kernel with this module enabled.
Thanks,
Mani
HI Mani,
Thank you so much. I compiled my kernel with the CONFIG_USB_SERIAL_OPTION
set.
and I have got the GSM and all that I needed to recover the board.
And the recovery process was successful.
But, now I am looking for a way to install a kernel that I have built to test my USB driver.
Is that a flow that you would suggest?
Regards,
Artur
Hi @arturp,
Glad to hear that you have recovered HiKey board. For testing the kernel, I would suggest you to install the debian image first as per below link and do a full update:
Once debian is installed on Hikey, then you can just update the kernel (as a debian package) by following the below guide:
Thanks,
Mani
Were you running a custom kernel or was this option not enabled in your distro?
Yes, I am running a custom kernel. Which didn’t include the CONFIG_USB_SERIAL_OPTION configuration.
Now I am trying to build and use a custom kernel on the board but there is a problem with some dependencies
with libssl-dev.
dpkg-buildpackage: host architecture arm64
dpkg-buildpackage: warning: debian/rules is not executable; fixing that
dpkg-source --before-build build
dpkg-checkbuilddeps: error: Unmet build dependencies: libssl-dev
dpkg-buildpackage: warning: build dependencies/conflicts unsatisfied; aborting
dpkg-buildpackage: warning: (Use -d flag to override.)
…/scripts/package/Makefile:75: recipe for target ‘bindeb-pkg’ failed
make[3]: *** [bindeb-pkg] Error 3
/home/buildroot/hikey/linux/Makefile:1345: recipe for target ‘bindeb-pkg’ failed
make[2]: *** [bindeb-pkg] Error 2
Makefile:146: recipe for target ‘sub-make’ failed
make[1]: *** [sub-make] Error 2
Makefile:24: recipe for target ‘__sub-make’ failed
make: *** [__sub-make] Error 2
Thanks… this came up late in this thread because it is unusual for a distro kernel to disable this feature. I just wanted to check we didn’t miss something.
For the ssl-dev problem this is a quirk of cross-building debian packages that we have not been able to reproduce (and could easily be a distro bug). Either way @Mani has propose a workaround):
Actually we should revert this commit: https://github.com/suihkulokki/linux/commit/609b507d299b8e59f2ceac95683f31f38a44efcb
Not sure why @suihkulokki added this.
-Mani
/me feels the light bulb turn on…
So it worked when I tested it because I tested an upstream kernel
I have found this which solves the dependency problem
but now there is another issue
arch/arm64/Makefile:48: Detected assembler with broken .inst; disassembly will be unreliable
CHK include/config/kernel.release
/bin/bash ./scripts/package/builddeb
cp: cannot stat ‘System.map’: No such file or directory
scripts/package/Makefile:79: recipe for target ‘intdeb-pkg’ failed
make[4]: *** [intdeb-pkg] Error 1
do you know what is this about?
Can you do a clean build? Something might have screwed up!
$ make clean distclean
Also it is good to check the compiler/binutils version you are using.