EEVblog Electronics Community Forum
Electronics => Repair => Topic started by: Yamin on February 13, 2020, 04:42:59 pm
-
Hi there everybody,
Sometime back I received a faulty guitar effects pedal board, it quite famous among the guitarist apparently. The unit does not boot up, goes through a start up sequence and just turns off. The main board is made up of Rockchip RK3288. Doing an internet search showed that a lot of people was going though the same situation. Nothing seems to get the unit to start back up - resetting etc.
The manufacture seems to not acknowledge this known issue and weren't very helpful. However I was able to source a spare board from the party which manufactures the main board.
Installing the new board rectified the problem, but after about three weeks the same thing happened. This time I was able to get it back to life by pressing the reset button, after couple of months it strikes again. This time however I was not able to get it back to life with the reset button. The guitarist it not really interested in reviving it anymore. So I thought I will just mess with just for my personal reference.
So as I said the microprocessor used Rockchip RK3288, the power management IC used is the ACT8846. I tried to find any obviously faulty components, couldn't find it. Going through the datasheet for the ACT8846 I found out that there was a way to manually reset the processor by shorting nPBIN to ground. I tried this but no difference. Start up sequence seems to work I even get 5V at the PWRHLD pin for a moment and it goes back to 0V. The nPBSTAT is used to fire an interrupt and it seems to be doing that as well. But the power doesn't latch. The button used to turn on the unit is one of those momentary push buttons which I assume fires some kind of an interrupt. If I press and hold this button, the voltage tends to remain at the pins for as long as I hold it.
I am quite new to troubleshooting circuits including microprocessors. Not having the schematic makes it that much harder. Just trying to 'solidly' figure out what the issue could be, even though I am not able to fix it. Any tips/help troubleshooting this would be greatly appreciated.
At this moment I am using the old mainboard with nothing else attached (buttons etc) only the 12V power supply.
Rockchip RK3288 datasheet -
http://webcache.googleusercontent.com/search?q=cache:http://opensource.rock-chips.com/images/4/4e/Rockchip_RK3288_Datasheet_V2.2-20170301.pdf (http://webcache.googleusercontent.com/search?q=cache:http://opensource.rock-chips.com/images/4/4e/Rockchip_RK3288_Datasheet_V2.2-20170301.pdf)
-
Check the battery cell, on a different system with a dead battery it simply refused to boot ???
my 2 cents.
Is it booting thru an sd card ? maybe the card is corrupted, i have a board with an imx25 cpu with an winCE 6.0 OS who did that symptom, the card had too many read and writes cycles ... changed it for an sandisk brand it was a kingston before, everything is now fine.
-
I did check the battery it seems to have charge.
There is no SD card, I had a similar case with another effects pedal where the SD card contact was a bit tarnished. I cleaned it and it started working.
Any suggestion on reading materials for troubleshooting microprocessor circuitry?
Thanks so much for your help.
-
I would measure the output voltages of each of the switchmode supplies and LDO regulators.
Given the symptoms, I'm wondering whether there is something wrong with the power-up sequence. The PMIC is programmed to power up each supply in a predefined order, so I'm thinking that the uP might get hung up if each supply doesn't come up at the right time.
-
If this product is running embedded Linux and it is powered on and off with a mechanical switch, there is a chance the filesystem is getting corrupt (if it is poorly designed). I have seen this in certain products.
-
I would measure the output voltages of each of the switchmode supplies and LDO regulators.
Given the symptoms, I'm wondering whether there is something wrong with the power-up sequence. The PMIC is programmed to power up each supply in a predefined order, so I'm thinking that the uP might get hung up if each supply doesn't come up at the right time.
Probably a very newbie question, but what is LDO? I came across that on the datasheet as well.
Make sense with the point you made about the power up sequence - would there be any way to know what the power up sequence should be or is it only known for the manufactures?
-
If this product is running embedded Linux and it is powered on and off with a mechanical switch, there is a chance the filesystem is getting corrupt (if it is poorly designed). I have seen this in certain products.
This was my thought as well, and that's what a lot of people are speculating for this particular unit. However would there be any way to conclusively find whether that is the problem.
-
If this product is running embedded Linux and it is powered on and off with a mechanical switch, there is a chance the filesystem is getting corrupt (if it is poorly designed). I have seen this in certain products.
This was my thought as well, and that's what a lot of people are speculating for this particular unit. However would there be any way to conclusively find whether that is the problem.
In this case, I would try to find three pins that would correspond to a UART port (maybe marked on the silk as TX, RX and GND) and connect a serial cable to a terminal program on a computer, configuring it to 115200 baud, 8 bits, no parity, 1 stop bit and no handshake (these are the most common settings for such ports in the marketplace).
Turning on the equipment, you should see a MLO/U-boot prompt, which will follow a sequence of operations with diagnostic messages.
If they have this filesystem indeed in flash, they should have furnished the board with enough RAM to hold the filesystem there. U-boot allows uncompressing the kernel and filesystem to RAM, which has the benefit that any corruption caused by the mechanical on/off would be simply vanished.
Another issue I have seen is the simple corruption of an ailing Flash device. This can be caused by either the processor itself (I have seen earlier Linux-based processors have bad NAND or NOR Flash controllers) or the Flash IC itself (either a ad devices or simply second-hand ones in the most inescrupulous manufacturers).
-
In this case, I would try to find three pins that would correspond to a UART port (maybe marked on the silk as TX, RX and GND) and connect a serial cable to a terminal program on a computer, configuring it to 115200 baud, 8 bits, no parity, 1 stop bit and no handshake (these are the most common settings for such ports in the marketplace).
There *is* a debug port, even noted as such and Comes with a header - even though it has four pins, that might be the way to go, probably just one pin not connected...
-
In this case, I would try to find three pins that would correspond to a UART port (maybe marked on the silk as TX, RX and GND) and connect a serial cable to a terminal program on a computer, configuring it to 115200 baud, 8 bits, no parity, 1 stop bit and no handshake (these are the most common settings for such ports in the marketplace).
There *is* a debug port, even noted as such and Comes with a header - even though it has four pins, that might be the way to go, probably just one pin not connected...
Yeah, I just saw that on the photograph. Although four pins could also be JTAG (TCK, TDI, TDO, TMS, with GND being somewhere else). Check the connections with a continuity tester.
-
In this case, I would try to find three pins that would correspond to a UART port (maybe marked on the silk as TX, RX and GND) and connect a serial cable to a terminal program on a computer, configuring it to 115200 baud, 8 bits, no parity, 1 stop bit and no handshake (these are the most common settings for such ports in the marketplace).
There *is* a debug port, even noted as such and Comes with a header - even though it has four pins, that might be the way to go, probably just one pin not connected...
And the 5 pins white connector near the 4 pins header ??
Yeah, I just saw that on the photograph. Although four pins could also be JTAG (TCK, TDI, TDO, TMS, with GND being somewhere else). Check the connections with a continuity tester.
Could be an serial or jtag port, as written check for a ground pin and an 5v or 3.3vdc pin .... and do a continuity check to the voltages regulators once you find the main ones ...
And the 5 pins white header near the 4 pins ??? what does it do ?
-
And the 5 pins white header near the 4 pins ??? what does it do ?
My guesstimate is "USB header" - a better picture would help (it's stated on the PCB, but only "SB" is readable).
-
LDO = low dropout, used to describe a linear regulator which can work in environments where there is a low differential between input and output.
-
Wow, thanks so much guys! Its getting very exciting. I shall take a picture first thing in the morning when I get into the shop and upload it here.
-
Here are some close up photos of the connectors.
-
I'm just curious. What are the complete markings on the ACT8846 chip? Is there a "490" marking anywhere?
-
I'm just curious. What are the complete markings on the ACT8846 chip? Is there a "490" marking anywhere?
There is no marking "490" may I ask what that means?
-
There are different versions of the ACT8846 which are preprogrammed with different voltages and different power-up sequences for each specific SoC. The RK3288 requires the ACT8846QM490 version (see pages 3 & 34 of datasheet).
-
Hi all
First of all, happy new year 2022 :D
I'm owner of a 2nd hand HR Pedalboard, and facing a known issue on this pedalboard effect that is related to USB.
USB connect to my laptop has been working twice, but since 2 weeks, no possibility to connect, I have checked the USB wire with some others, tested on 3 different laptop with different OS running on, and different USB port. I still doesn't work.
I have been reading different forum speaking about this known issue where, Headrush sometime fix it by changing the motherboard, or you need to buy a new one an fix it yourself ... when you see the original price of the pedalboard and the cost for a new motherboard, that is just amazing :-[
Mine still power up, but I can't add new IR or RIG because of the USB issue ... I have been looking inside the main motherboard that you are speaking about on this forum, and I'm wondering what could be the 2 buttons (Reset / Recovery ) ?
-
Some updates on my investigations
After having unmounted the pedalboard, I found a motherboard that looks like the one of MPC Live.
I have connected a wire Serial to USB and use TeraTerm.
(https://medias.audiofanzine.com/img/pictures/normal/4/1/4147326.jpg?fm=pjpg&w=1020&fit=max&s=1bdd325f11f14ed4a16218fd4be8dcce)
I have errors in the output of the terminal connected during the boot sequence :
...
001: dwc2 ff540000.usb: ff540000.usb supply vusb_d not found, using dummy regulator
001: dwc2 ff540000.usb: ff540000.usb supply vusb_a not found, using dummy regulator
001: dwc2 ff540000.usb: dwc2_check_params: Invalid parameter lpm_clock_gating=1
001: dwc2 ff540000.usb: dwc2_check_params: Invalid parameter besl=1
001: dwc2 ff540000.usb: dwc2_check_params: Invalid parameter hird_threshold_en=1
...
001: usb5537 1-002d: Failed to write config file
001: usb5537 1-002d: failed to switch mode: -6
...
I have then a prompt for login, it is a linux running, but no chance to log into with root even with blank password :(
Also when I put the headrush in Update Firmware mode from the screen touch (same as starting with recovery button on the motherboard), in the output of the terminal, I have this message
Starting fastboot...
ERROR: usb5537_write_config: failed to write config file: ret=-121
at drivers/misc/usb5537.c:69/usb5537_write_config()
ERROR: board_usb_init: failed to probe usb5537@2d: ret=-121
at board/inmusic/az01/az01.c:525/board_usb_init()
otg_phy_init
I don't know if that could be a software issue or hardware issue for the moment but if those information can help to investigate let me know :)
-
Hum if i recall you have Rockchip tools (softwares) to format / install ose's / boot files etc ...
http://opensource.rock-chips.com/wiki_RK3288 (http://opensource.rock-chips.com/wiki_RK3288)
forum.xda-developers.com is a very good source for help and softwraes links, memory locations etc ...
The recovery button should help, do you see something on the serial console upon powering it up with recovery pressed ??
This board is a computer but only the I2S interface (flat cable) seems to be used ??
Is the pedal maker can send you a recovery file if you mail them, some special application file / os etc ... may be needed for the recovery
We dont have many details to work with, company / model can or could help ?
And i see you have posted at least 2 times on other web sites
-
Hi, thanks for your answer,
Here is a link to all technical details of the pedalboard https://apps.fcc.gov/oetcf/eas/reports/ViewExhibitReport.cfm?mode=Exhibits&RequestTimeout=500&calledFromFrame=Y&application_id=nkZwk1kzGEhR9dsGu%2FseSA%3D%3D&fcc_id=Y4O-MG01 (https://apps.fcc.gov/oetcf/eas/reports/ViewExhibitReport.cfm?mode=Exhibits&RequestTimeout=500&calledFromFrame=Y&application_id=nkZwk1kzGEhR9dsGu%2FseSA%3D%3D&fcc_id=Y4O-MG01)
The exact reference is : InMusic AZ01 CR PCB 9-40-0752-C / 9-79-0752-C 2017-FEB-14 Most of MPC stuff from AKAI are based on the same motherboard.
Replacement part looks like this https://instrumentalparts.com/pcb-carrier-assembly-headrush/ (https://instrumentalparts.com/pcb-carrier-assembly-headrush/)
(https://cdn11.bigcommerce.com/s-pdowf1mync/images/stencil/1280x1280/products/363231/115952/AL9-79-075203__10585.1616682756.jpg?c=2)
Yes it is based on a RK3288, I have contacted Headrush to get the root password and a recovery file but no answer, just paying so they might potentially fix it but for lot money ... I posted also on MPC AKAI forums in case of similar known issue.
When I boot in Recovery mode, I have this output :
U-Boot SPL 2016.05-inmusic-20170317 (Apr 13 2017 - 19:55:47)
Trying to boot from MMC1
U-Boot 2016.05-inmusic-20170317 (Apr 13 2017 - 19:55:47 +0200), Build: jenkins-RadXa CustomBuilder-1459
Model: Eleven
DRAM: 1 GiB
MMC: dwmmc@ff0f0000: 0
In: gpio-keys
Out: serial
Err: serial
Hit any key to stop autoboot: 0
Starting fastboot...
ERROR: usb5537_write_config: failed to write config file: ret=-121
at drivers/misc/usb5537.c:69/usb5537_write_config()
ERROR: board_usb_init: failed to probe usb5537@2d: ret=-121
at board/inmusic/az01/az01.c:525/board_usb_init()
otg_phy_init
It confirms that there is an issue with USB port ...
I will have a look to forum.xda-developers.com that could help a lot :)
-
We do see RADXA logo on the fcc aproval board links provided
Maybe they have some tools of firmware to help ??
You best luck will be someone who could extract the boot / config files ??? seems like somekind of memory corruption ??
Does it boot on the SD-Card ??
Our embedded boards had some problems with sd-card ''wear and tear'' we had Kingston before and had to choose Sandisk, lots of problems where solved
If you search this wiki : https://fr.wikipedia.org/wiki/Rockchip_RK3288
You will see many derived RK3288 boards
Maybe you could find some development tools and os to boot from or recover some parts ??
or Radxa home :
https://wiki.radxa.com/Home
https://wiki.radxa.com/Rock2/bringup
Akai MPC Live ??
https://niklasnisbeth.gitlab.io/mpc-internals/#the-software seems to point to an OS and files ??
Unless the usb driver chip has some problems, check if you have an usb interface chip somewhere outside the SOM RK3288 module, maybe its kinda busted on one chanel ?
-
So, this is HeadRush Pedalboard, right?
In simple terms, the device is an embedded Linux appliance: a small single-board computer using RockChip RK3288 System-On-Chip, running some variant of Linux, and some userspace software providing the user interface.
at drivers/misc/usb5537.c:69/usb5537_write_config()
ERROR: board_usb_init: failed to probe usb5537@2d: ret=-121
USB5537 refers to an USB 3.0/2.0 7-port hub. In the image, you can see at least three of them exposed in pin headers (but without any pins); some of the unpopulated connectors near the top of the image are also USB ports.
However, I cannot find the kernel driver, drivers/misc/usb5537.c, anywhere. It is obviously an out-of-tree driver for thus USB hub, not developed by open-source developers (definitely not kernel.org) and it is not in RockChip kernel trees either. It is the first point I'd start looking for a problem, but since the sources are nowhere to be found, it's a no go. Apparently, copyright law is not something HeadRush is interested in following.
None of the HeadRush firmware files or user guides mention Linux. The license they are breaking by not providing sources for the modified Linux kernel they are using, is the only thing that permits them to use the Linux kernel in their product. This means that software-wise, none of the Linux kernel developers like myself can help you with this.
If I were you, I'd raise a fuckstink at HeadRush for breaking copyright law, and not providing the sources for the GPL-licensed software they are selling as a key part of this device. :rant:
If you at some point do get the exact sources for at least the kernel used in the product –– and that means the exact ones, including the usb5537.c file, and not just "it's a 4.4 kernel" because the fuck it is; the 4.4 kernels do not have that file nor are able to produce that error output you are getting, and what is used on that thing is not a normal Linux kernel, but a modified one ––, then it would be a quick matter of checking out the usb5537 driver if it could be the source of the issues. Who knows, it might have an obfuscated check to stop operating after some (randomized) interval, just to make sure you guitarists keep buying new pedalboards.
(Really, it's more like how fragile the driver is wrt. timeouts, response intervals and such, that change as the hardware ages and things like capacitors degrade a little bit. It is easy to write a driver that works with perfect hardware, but a proper driver that is robust against that kind of variation, requires common sense and a lot of experience. Which cheap developers that copy-paste code from the internet –– which is what the names shown in the log indicates; I can see similar names in microcontroller examples for controlling the USB5537B chip, which indicates that the "driver" is basically a copy-paste hack-job to get the hub chip "working". And because it is a low-grade hack, it often doesn't, causing a lot of lost money and wasted pedalboards. HeadRush doesn't mind, because you customers keep buying new devices to replace the "broken" ones.)
The reason I'm so angry is that customers don't care, and tend to just blame us open source developers for making "a crappy Linux that failed in my pedalboard". Because we didn't, HeadRush did, by fucking with the kernel. The results you have in your hands, with HeadRush laughing at us all the way to the bank. And RockChip (the designers of the RK3x88 chips) happens to be one of the rare Chinese designer firms that do publish the changes needed for the Linux kernel to support their chips and even push changes to the upstream Linux kernel developers; companies like Allwinner just give a middle finger to everybody, because they cannot be sued in any Western country for copyright violations, they don't need to care. So, this is Annoying.
Besides, even if one would get full sources to the kernel, HeadRush will never ever publish enough sources for you to generate a replacement firmware fixing the software issue –– assuming it is one ––, so you're fucked with this thing anyway. (Even if somebody like me finds the bug in the driver, and provides a fix, what is the likelihood that HeadRush accepts the fix and produces a new firmware fixing the issues? They'd only be reducing their future sales, because their old products would be usable for longer.)
Unless, of course, it is a pure hardware issue. Which I don't think it is, because it works well enough to boot into the Linux kernel.
>:(
-
Hi guys, thanks a lot for your contributions
@Nominal Animal, I confirm it is a headrush pedalboard.
I'm now able to login on serial port as root.
When the Headrush was booting, I was stopping boot at the beginning by typing any key, to be in "low boot level" ...
Then, what I did :
$>printenv bootargs
$>bootargs=root=PARTUUID=24d1deac-3434-1a4e-98d1-68ee2945a5f1 rootwait ro console=ttyS2,115200 rfkill.default_state=0
$>setenv bootargs 'root=PARTUUID=24d1deac-3434-1a4e-98d1-68ee2945a5f1 rootwait ro console=ttyS2,115200 rfkill.default_state=0 single init=/bin/sh'
$>boot
$>mount -rw -o remount /
$>passwd root
$>reboot -f
Then I was able to log as root into the headrush.
I'm not a Linux expert, I use to work with like 20 years ago ... but as you said I would be surprise that it is a hardware issue ... I agree with you they don't give any access to source code ... I emailed AKAI support to get a fix but no possibility to get any software assistance, just send the unit back on my own cost then they will have a look to fix it.
There is no SD card on the board. There are some logs still running and making the FS growing :o
I'm technical guy and I like to understand why things are not working well, in that case if it is a software issue, it should be an easy one to fix it instead of a hardware issue and save lot of money for music players.
$>dmessg
...
[ 0.078590] phy phy-ff770000.syscon:usbphy.0: Looking up phy-supply from device tree
[ 0.078597] phy phy-ff770000.syscon:usbphy.0: Looking up phy-supply property in node /syscon@ff770000/usbphy/usb-phy@320 failed
[ 0.078656] phy phy-ff770000.syscon:usbphy.0: Looking up vbus-supply from device tree
[ 0.078661] phy phy-ff770000.syscon:usbphy.0: Looking up vbus-supply property in node /syscon@ff770000/usbphy/usb-phy@320 failed
[ 0.078853] phy phy-ff770000.syscon:usbphy.1: Looking up phy-supply from device tree
[ 0.078858] phy phy-ff770000.syscon:usbphy.1: Looking up phy-supply property in node /syscon@ff770000/usbphy/usb-phy@334 failed
[ 0.078899] phy phy-ff770000.syscon:usbphy.1: Looking up vbus-supply from device tree
[ 0.078904] phy phy-ff770000.syscon:usbphy.1: Looking up vbus-supply property in node /syscon@ff770000/usbphy/usb-phy@334 failed
[ 0.079080] phy phy-ff770000.syscon:usbphy.2: Looking up phy-supply from device tree
[ 0.079085] phy phy-ff770000.syscon:usbphy.2: Looking up phy-supply property in node /syscon@ff770000/usbphy/usb-phy@348 failed
[ 0.079125] phy phy-ff770000.syscon:usbphy.2: Looking up vbus-supply from device tree
[ 0.079130] phy phy-ff770000.syscon:usbphy.2: Looking up vbus-supply property in node /syscon@ff770000/usbphy/usb-phy@348 failed
[ 0.079721] pwm-backlight mipi-backlight: Looking up power-supply from device tree
...
[ 1.761182] dwc2 ff540000.usb: Looking up vusb_d-supply from device tree
[ 1.761188] dwc2 ff540000.usb: Looking up vusb_d-supply property in node /usb@ff540000 failed
[ 1.761208] dwc2 ff540000.usb: ff540000.usb supply vusb_d not found, using dummy regulator
[ 1.761247] dwc2 ff540000.usb: Looking up vusb_a-supply from device tree
[ 1.761252] dwc2 ff540000.usb: Looking up vusb_a-supply property in node /usb@ff540000 failed
[ 1.761264] dwc2 ff540000.usb: ff540000.usb supply vusb_a not found, using dummy regulator
[ 1.761393] dwc2 ff540000.usb: Looking up vbus-supply from device tree
[ 1.761399] dwc2 ff540000.usb: Looking up vbus-supply property in node /usb@ff540000 failed
[ 1.812571] dwc2 ff540000.usb: dwc2_check_params: Invalid parameter lpm_clock_gating=1
[ 1.812576] dwc2 ff540000.usb: dwc2_check_params: Invalid parameter besl=1
[ 1.812579] dwc2 ff540000.usb: dwc2_check_params: Invalid parameter hird_threshold_en=1
[ 1.812699] dwc2 ff540000.usb: DWC OTG Controller
[ 1.812714] dwc2 ff540000.usb: new USB bus registered, assigned bus number 1
[ 1.812851] usb usb1: New USB device found, idVendor=1d6b, idProduct=0002, bcdDevice= 5.04
[ 1.812857] usb usb1: New USB device strings: Mfr=3, Product=2, SerialNumber=1
[ 1.812861] usb usb1: Product: DWC OTG Controller
[ 1.812864] usb usb1: Manufacturer: Linux 5.4.115-inmusic-2021-04-30-rt56 dwc2_hsotg
[ 1.812867] usb usb1: SerialNumber: ff540000.usb
[ 1.813152] hub 1-0:1.0: USB hub found
[ 1.813174] hub 1-0:1.0: 1 port detected
[ 1.813502] dwc2 ff580000.usb: Looking up vusb_d-supply from device tree
[ 1.813508] dwc2 ff580000.usb: Looking up vusb_d-supply property in node /usb@ff580000 failed
[ 1.813523] dwc2 ff580000.usb: ff580000.usb supply vusb_d not found, using dummy regulator
[ 1.813599] dwc2 ff580000.usb: Looking up vusb_a-supply from device tree
[ 1.813605] dwc2 ff580000.usb: Looking up vusb_a-supply property in node /usb@ff580000 failed
[ 1.813618] dwc2 ff580000.usb: ff580000.usb supply vusb_a not found, using dummy regulator
[ 1.813744] dwc2 ff580000.usb: Looking up vbus-supply from device tree
[ 1.813750] dwc2 ff580000.usb: Looking up vbus-supply property in node /usb@ff580000 failed
[ 1.935570] dwc2 ff580000.usb: dwc2_check_params: Invalid parameter lpm_clock_gating=1
[ 1.935575] dwc2 ff580000.usb: dwc2_check_params: Invalid parameter besl=1
[ 1.935578] dwc2 ff580000.usb: dwc2_check_params: Invalid parameter hird_threshold_en=1
[ 1.935592] dwc2 ff580000.usb: EPs: 10, dedicated fifos, 972 entries in SPRAM
[ 1.935651] dwc2 ff580000.usb: DWC OTG Controller
[ 1.935665] dwc2 ff580000.usb: new USB bus registered, assigned bus number 2
[ 1.935773] usb usb2: New USB device found, idVendor=1d6b, idProduct=0002, bcdDevice= 5.04
[ 1.935778] usb usb2: New USB device strings: Mfr=3, Product=2, SerialNumber=1
[ 1.935782] usb usb2: Product: DWC OTG Controller
[ 1.935785] usb usb2: Manufacturer: Linux 5.4.115-inmusic-2021-04-30-rt56 dwc2_hsotg
[ 1.935788] usb usb2: SerialNumber: ff580000.usb
[ 1.936093] hub 2-0:1.0: USB hub found
[ 1.936113] hub 2-0:1.0: 1 port detected
$># lsusb -v
Bus 003 Device 001: ID 1d6b:0002
Bus 001 Device 001: ID 1d6b:0002
Bus 001 Device 002: ID 0763:0016
Bus 002 Device 001: ID 1d6b:0002
I have seen that there are known issues with the fact that USB port could be in a bad situation, specifically for those where you plug/unplug USB wire without unmounting properly.
It seems that there is a potential solution there https://lkml.org/lkml/2016/8/21/29 (https://lkml.org/lkml/2016/8/21/29) but I don't know how I can apply that.
or https://linux-arm-kernel.infradead.narkive.com/Q7dsQsVn/patch-3-4-arm-dts-rockchip-enable-the-usb-phys-as-reset-providers-on-rk3288 (https://linux-arm-kernel.infradead.narkive.com/Q7dsQsVn/patch-3-4-arm-dts-rockchip-enable-the-usb-phys-as-reset-providers-on-rk3288)
I didn't find anything in the tree of the unit :(
As you said unless if they give the source code to fix in usb5537.c or other files they might not accept to integrate into future release.
When I see on music forums number of music players impacted by this issue without good responses of headrush support.
https://www.thegearpage.net/board/index.php?threads/headrush-usb-problem.1890675/ (https://www.thegearpage.net/board/index.php?threads/headrush-usb-problem.1890675/)
@coromonadalix thanks for the links I will have a look.
-
I emailed AKAI support to get a fix but no possibility to get any software assistance, just send the unit back on my own cost then they will have a look to fix it.
Yeah; sorry if I sounded too angry there, but this is the case with way too many Linux-based appliances. Way too many routers for example are vulnerable to attacks and are easily subverted to become a part of a botnet –– but not because Linux is inherently vulnerable or needs to be constant updates to stay secure, but more because most of the software that implements the appliance is just so full of security holes it is ridiculous. To me, it is like seeing someone smear shit on the walls and laugh.
Also, to be clear: Tux is my mascot, not my idol; and I'm not a GPL zealot. I use a lot of different licenses, including CC-1.0 for my code examples, proprietary licenses for commercial work, BSD/MIT/Apache for some libraries, and GPL only when doing either already-GPL-licensed stuff or when I deem it the most appropriate for the product at hand. License is just one of the tools for me. Seeing others misuse them is like seeing people try to hammer screws in.
[ 1.812699] dwc2 ff540000.usb: DWC OTG Controller
[ 1.812714] dwc2 ff540000.usb: new USB bus registered, assigned bus number 1
[ 1.812851] usb usb1: New USB device found, idVendor=1d6b, idProduct=0002, bcdDevice= 5.04
[ 1.812857] usb usb1: New USB device strings: Mfr=3, Product=2, SerialNumber=1
[ 1.812861] usb usb1: Product: DWC OTG Controller
[ 1.812864] usb usb1: Manufacturer: Linux 5.4.115-inmusic-2021-04-30-rt56 dwc2_hsotg
[ 1.812867] usb usb1: SerialNumber: ff540000.usb
[ 1.813152] hub 1-0:1.0: USB hub found
[ 1.813174] hub 1-0:1.0: 1 port detected
That means usb1 is the USB On-The-Go port, using a DesignWare chip (not the USB5537), and works fine. (In other words, the On-The-Go port should work fine.)
[ 1.935665] dwc2 ff580000.usb: new USB bus registered, assigned bus number 2
[ 1.935773] usb usb2: New USB device found, idVendor=1d6b, idProduct=0002, bcdDevice= 5.04
[ 1.935778] usb usb2: New USB device strings: Mfr=3, Product=2, SerialNumber=1
[ 1.935782] usb usb2: Product: DWC OTG Controller
[ 1.935785] usb usb2: Manufacturer: Linux 5.4.115-inmusic-2021-04-30-rt56 dwc2_hsotg
[ 1.935788] usb usb2: SerialNumber: ff580000.usb
[ 1.936093] hub 2-0:1.0: USB hub found
[ 1.936113] hub 2-0:1.0: 1 port detected
Funky; it has two USB On-The-Go ports! Both should be working just fine.
Bus 003 Device 001: ID 1d6b:0002
Bus 001 Device 001: ID 1d6b:0002
Bus 001 Device 002: ID 0763:0016
Bus 002 Device 001: ID 1d6b:0002
Now, this one is very useful. From the above, we already know that Bus 001 Device 001 and Bus 002 Device 001 are USB On-The-Go ports using the standard kernel dwc2 (https://elixir.bootlin.com/linux/latest/source/drivers/usb/dwc2) driver (for DesignWare high-speed On-The-Go USB controllers); it looks like there is even a third one, heh –– which makes sense, actually; parts cost and whatnot.
(1d6b:0002 just means generic USB 2.0 root hub; the 1d6b identifier is "Linux Foundation".)
There is only one USB device connected, and that is to the first on-the-go bus: ID 0736:0016 0763:0016.
0736 is the Manufacturer ID for M-Audio, but its product 0016 is not listed in the Linux USB device ID list (http://www.linux-usb.org/usb-ids.html).
Could you run lsusb -vvv (as root on the device), and copy the part that begins with Bus 001 Device 002: ID 0763:0016 until an empty line? It would provide all information the kernel knows about the device. I am especially interested in the 'bDeviceClass', which I suspect to be '9 Hub', and this device be the actual USB5537B hub chip. (If so, it means the actual chip is not fully busted at least, because the chip that it is connected to still enumerates it just fine; it would be a very strong indicator that the issue is crappy code in usb5537.c that cannot deal with the normal age-related variances in system behaviour. Typical for thrown-together low-quality code!)
-
Hello, I a new on this forum i was googling for MPC and find your post.
On my side I own a MPC Akai Force with a customm Firmware allowing to connect on the SSH.
All theses boards (Headrush Gigboard / Denon Prime or Akai MPC Live/Force share the same SOC with RK3288 .
You can find useful information on this github :
https://github.com/TheKikGen (https://github.com/TheKikGen)
To connect via SSH instead of using serial cable, you can follow this guide :
https://github.com/TheKikGen/MPC-LiveXplore/wiki/Enabling-SSH-on-the-MPC-Live-X-one-Force (https://github.com/TheKikGen/MPC-LiveXplore/wiki/Enabling-SSH-on-the-MPC-Live-X-one-Force)
It should be the same way on the Headrush.
Concerning the img file provided :
You have a first .img which is packed, extract it with 7zip and you'll get another image file which approx 300/400 mb.
You can still open it with 7zip and extract the content.
You will find more information there too :
https://github.com/TheKikGen/MPC-LiveXplore/wiki/How-to-extract-the-2.6-rootfs-img-from-the-update.img (https://github.com/TheKikGen/MPC-LiveXplore/wiki/How-to-extract-the-2.6-rootfs-img-from-the-update.img)
You can explore the file and find useful information.
(https://i.ibb.co/wz4b8rS/Headrush.jpg)
Scripts allow to configure the board, and Evil is the main program for the Gigboard.
you can try to run it mannualy ( cd /usr/Evil , then ./Evil )
To restore your board, did you try to press the "recover" switch on the board ? Normally when you press it and start the board, this one switches to a special mode which allow you to restore a firmware on a USB Stick.
The request was not for me but fyi here is my full lsusb -vvv
# lsusb -vvv
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Device Descriptor:
bLength 18
bDescriptorType 1
bcdUSB 2.00
bDeviceClass 9 Hub
bDeviceSubClass 0
bDeviceProtocol 1 Single TT
bMaxPacketSize0 64
idVendor 0x1d6b Linux Foundation
idProduct 0x0002 2.0 root hub
bcdDevice 5.04
iManufacturer 3 Linux 5.4.130-inmusic-2021-07-08-rt59 dwc2_hsotg
iProduct 2 DWC OTG Controller
iSerial 1 ff580000.usb
bNumConfigurations 1
Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength 0x0019
bNumInterfaces 1
bConfigurationValue 1
iConfiguration 0
bmAttributes 0xe0
Self Powered
Remote Wakeup
MaxPower 0mA
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 0
bAlternateSetting 0
bNumEndpoints 1
bInterfaceClass 9 Hub
bInterfaceSubClass 0
bInterfaceProtocol 0 Full speed (or root) hub
iInterface 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x81 EP 1 IN
bmAttributes 3
Transfer Type Interrupt
Synch Type None
Usage Type Data
wMaxPacketSize 0x0004 1x 4 bytes
bInterval 12
Hub Descriptor:
bLength 9
bDescriptorType 41
nNbrPorts 1
wHubCharacteristic 0x0008
Ganged power switching
Per-port overcurrent protection
TT think time 8 FS bits
bPwrOn2PwrGood 1 * 2 milli seconds
bHubContrCurrent 0 milli Ampere
DeviceRemovable 0x00
PortPwrCtrlMask 0xff
Hub Port Status:
Port 1: 0000.0000
can't get device qualifier: Resource temporarily unavailable
can't get debug descriptor: Resource temporarily unavailable
Device Status: 0x0001
Self Powered
Bus 002 Device 003: ID 09e8:0040 AKAI Professional M.I. Corp. Akai Pro Force
Device Descriptor:
bLength 18
bDescriptorType 1
bcdUSB 2.00
bDeviceClass 0
bDeviceSubClass 0
bDeviceProtocol 0
bMaxPacketSize0 64
idVendor 0x09e8 AKAI Professional M.I. Corp.
idProduct 0x0040
bcdDevice 0.43
iManufacturer 1 Akai Pro
iProduct 2 Akai Pro Force
iSerial 0
bNumConfigurations 1
Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength 0x0078
bNumInterfaces 2
bConfigurationValue 1
iConfiguration 0
bmAttributes 0xc0
Self Powered
MaxPower 0mA
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 0
bAlternateSetting 0
bNumEndpoints 0
bInterfaceClass 1 Audio
bInterfaceSubClass 1 Control Device
bInterfaceProtocol 0
iInterface 0
AudioControl Interface Descriptor:
bLength 9
bDescriptorType 36
bDescriptorSubtype 1 (HEADER)
bcdADC 1.00
wTotalLength 0x0009
bInCollection 1
baInterfaceNr(0) 1
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 1
bAlternateSetting 0
bNumEndpoints 2
bInterfaceClass 1 Audio
bInterfaceSubClass 3 MIDI Streaming
bInterfaceProtocol 0
iInterface 0
MIDIStreaming Interface Descriptor:
bLength 7
bDescriptorType 36
bDescriptorSubtype 1 (HEADER)
bcdADC 1.00
wTotalLength 0x0054
MIDIStreaming Interface Descriptor:
bLength 6
bDescriptorType 36
bDescriptorSubtype 2 (MIDI_IN_JACK)
bJackType 1 Embedded
bJackID 1
iJack 6 (error)
MIDIStreaming Interface Descriptor:
bLength 6
bDescriptorType 36
bDescriptorSubtype 2 (MIDI_IN_JACK)
bJackType 1 Embedded
bJackID 2
iJack 7 (error)
MIDIStreaming Interface Descriptor:
bLength 6
bDescriptorType 36
bDescriptorSubtype 2 (MIDI_IN_JACK)
bJackType 1 Embedded
bJackID 3
iJack 8 (error)
MIDIStreaming Interface Descriptor:
bLength 9
bDescriptorType 36
bDescriptorSubtype 3 (MIDI_OUT_JACK)
bJackType 1 Embedded
bJackID 4
bNrInputPins 1
baSourceID( 0) 1
BaSourcePin( 0) 1
iJack 22 (error)
MIDIStreaming Interface Descriptor:
bLength 9
bDescriptorType 36
bDescriptorSubtype 3 (MIDI_OUT_JACK)
bJackType 1 Embedded
bJackID 5
bNrInputPins 1
baSourceID( 0) 2
BaSourcePin( 0) 1
iJack 23 (error)
MIDIStreaming Interface Descriptor:
bLength 9
bDescriptorType 36
bDescriptorSubtype 3 (MIDI_OUT_JACK)
bJackType 1 Embedded
bJackID 6
bNrInputPins 1
baSourceID( 0) 3
BaSourcePin( 0) 1
iJack 24 (error)
Endpoint Descriptor:
bLength 9
bDescriptorType 5
bEndpointAddress 0x01 EP 1 OUT
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0040 1x 64 bytes
bInterval 0
bRefresh 0
bSynchAddress 0
MIDIStreaming Endpoint Descriptor:
bLength 7
bDescriptorType 37
bDescriptorSubtype 1 (GENERAL)
bNumEmbMIDIJack 3
baAssocJackID( 0) 1
baAssocJackID( 1) 2
baAssocJackID( 2) 3
Endpoint Descriptor:
bLength 9
bDescriptorType 5
bEndpointAddress 0x81 EP 1 IN
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0040 1x 64 bytes
bInterval 0
bRefresh 0
bSynchAddress 0
MIDIStreaming Endpoint Descriptor:
bLength 7
bDescriptorType 37
bDescriptorSubtype 1 (GENERAL)
bNumEmbMIDIJack 3
baAssocJackID( 0) 4
baAssocJackID( 1) 5
baAssocJackID( 2) 6
can't get device qualifier: Resource temporarily unavailable
can't get debug descriptor: Resource temporarily unavailable
Device Status: 0x0001
Self Powered
Bus 002 Device 006: ID 09e8:703b AKAI Professional M.I. Corp. Card Reader
Device Descriptor:
bLength 18
bDescriptorType 1
bcdUSB 2.10
bDeviceClass 0
bDeviceSubClass 0
bDeviceProtocol 0
bMaxPacketSize0 64
idVendor 0x09e8 AKAI Professional M.I. Corp.
idProduct 0x703b
bcdDevice 8.28
iManufacturer 3 Akai MPC
iProduct 4 Card Reader
iSerial 5 000000000014
bNumConfigurations 1
Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength 0x0020
bNumInterfaces 1
bConfigurationValue 1
iConfiguration 0
bmAttributes 0x80
(Bus Powered)
MaxPower 500mA
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 0
bAlternateSetting 0
bNumEndpoints 2
bInterfaceClass 8 Mass Storage
bInterfaceSubClass 6 SCSI
bInterfaceProtocol 80 Bulk-Only
iInterface 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x81 EP 1 IN
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0200 1x 512 bytes
bInterval 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x02 EP 2 OUT
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0200 1x 512 bytes
bInterval 0
Binary Object Store Descriptor:
bLength 5
bDescriptorType 15
wTotalLength 0x002a
bNumDeviceCaps 3
USB 2.0 Extension Device Capability:
bLength 7
bDescriptorType 16
bDevCapabilityType 2
bmAttributes 0x00000f0e
BESL Link Power Management (LPM) Supported
BESL value 3840 us
SuperSpeed USB Device Capability:
bLength 10
bDescriptorType 16
bDevCapabilityType 3
bmAttributes 0x00
wSpeedsSupported 0x000e
Device can operate at Full Speed (12Mbps)
Device can operate at High Speed (480Mbps)
Device can operate at SuperSpeed (5Gbps)
bFunctionalitySupport 1
Lowest fully-functional device speed is Full Speed (12Mbps)
bU1DevExitLat 10 micro seconds
bU2DevExitLat 2047 micro seconds
Container ID Device Capability:
bLength 20
bDescriptorType 16
bDevCapabilityType 4
bReserved 0
ContainerID {8cf6c06a-4a90-f138-a5b1-4f6856b8ed90}
can't get debug descriptor: Resource temporarily unavailable
Device Status: 0x0000
(Bus Powered)
Bus 002 Device 005: ID 13e0:2517 TSE Inc. USB Mass Storage Device
Device Descriptor:
bLength 18
bDescriptorType 1
bcdUSB 2.00
bDeviceClass 0
bDeviceSubClass 0
bDeviceProtocol 0
bMaxPacketSize0 64
idVendor 0x13e0
idProduct 0x2517
bcdDevice 1.00
iManufacturer 1 TSE Inc.
iProduct 4 USB Mass Storage Device
iSerial 0
bNumConfigurations 1
Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength 0x0020
bNumInterfaces 1
bConfigurationValue 1
iConfiguration 0
bmAttributes 0xc0
Self Powered
MaxPower 0mA
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 0
bAlternateSetting 0
bNumEndpoints 2
bInterfaceClass 8 Mass Storage
bInterfaceSubClass 5 SFF-8070i
bInterfaceProtocol 80
iInterface 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x01 EP 1 OUT
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0200 1x 512 bytes
bInterval 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x82 EP 2 IN
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0200 1x 512 bytes
bInterval 0
Device Qualifier (for other device speed):
bLength 10
bDescriptorType 6
bcdUSB 2.00
bDeviceClass 0
bDeviceSubClass 0
bDeviceProtocol 0
bMaxPacketSize0 64
bNumConfigurations 1
can't get debug descriptor: Resource temporarily unavailable
Device Status: 0x0000
(Bus Powered)
Bus 002 Device 004: ID 13e0:2515 TSE Inc. USB Embedded Hub
Device Descriptor:
bLength 18
bDescriptorType 1
bcdUSB 2.00
bDeviceClass 9 Hub
bDeviceSubClass 0
bDeviceProtocol 1 Single TT
bMaxPacketSize0 64
idVendor 0x13e0
idProduct 0x2515
bcdDevice 1.00
iManufacturer 1 TSE Inc.
iProduct 3 USB Embedded Hub
iSerial 0
bNumConfigurations 1
Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength 0x0022
bNumInterfaces 1
bConfigurationValue 1
iConfiguration 0
bmAttributes 0xc0
Self Powered
MaxPower 100mA
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 0
bAlternateSetting 0
bNumEndpoints 1
bInterfaceClass 9 Hub
bInterfaceSubClass 0
bInterfaceProtocol 0 Full speed (or root) hub
iInterface 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x81 EP 1 IN
bmAttributes 3
Transfer Type Interrupt
Synch Type None
Usage Type Data
wMaxPacketSize 0x0001 1x 1 bytes
bInterval 12
** UNRECOGNIZED: 09 29 01 0d 00 32 64 02 ff
Hub Descriptor:
bLength 9
bDescriptorType 41
nNbrPorts 1
wHubCharacteristic 0x000d
Per-port power switching
Compound device
Per-port overcurrent protection
TT think time 8 FS bits
bPwrOn2PwrGood 50 * 2 milli seconds
bHubContrCurrent 100 milli Ampere
DeviceRemovable 0x02
PortPwrCtrlMask 0xff
Hub Port Status:
Port 1: 0000.0503 highspeed power enable connect
Device Qualifier (for other device speed):
bLength 10
bDescriptorType 6
bcdUSB 2.00
bDeviceClass 9 Hub
bDeviceSubClass 0
bDeviceProtocol 0 Full speed (or root) hub
bMaxPacketSize0 64
bNumConfigurations 1
can't get debug descriptor: Resource temporarily unavailable
Device Status: 0x0001
Self Powered
Bus 002 Device 002: ID 09e8:5040 AKAI Professional M.I. Corp. Force Hub
Device Descriptor:
bLength 18
bDescriptorType 1
bcdUSB 2.10
bDeviceClass 9 Hub
bDeviceSubClass 0
bDeviceProtocol 2 TT per port
bMaxPacketSize0 64
idVendor 0x09e8 AKAI Professional M.I. Corp.
idProduct 0x5040
bcdDevice 50.00
iManufacturer 1 Akai Professional
iProduct 2 Force Hub
iSerial 0
bNumConfigurations 1
Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength 0x0029
bNumInterfaces 1
bConfigurationValue 1
iConfiguration 0
bmAttributes 0xe0
Self Powered
Remote Wakeup
MaxPower 0mA
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 0
bAlternateSetting 0
bNumEndpoints 1
bInterfaceClass 9 Hub
bInterfaceSubClass 0
bInterfaceProtocol 1 Single TT
iInterface 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x81 EP 1 IN
bmAttributes 3
Transfer Type Interrupt
Synch Type None
Usage Type Data
wMaxPacketSize 0x0001 1x 1 bytes
bInterval 12
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 0
bAlternateSetting 1
bNumEndpoints 1
bInterfaceClass 9 Hub
bInterfaceSubClass 0
bInterfaceProtocol 2 TT per port
iInterface 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x81 EP 1 IN
bmAttributes 3
Transfer Type Interrupt
Synch Type None
Usage Type Data
wMaxPacketSize 0x0001 1x 1 bytes
bInterval 12
Hub Descriptor:
bLength 9
bDescriptorType 41
nNbrPorts 7
wHubCharacteristic 0x000d
Per-port power switching
Compound device
Per-port overcurrent protection
TT think time 8 FS bits
bPwrOn2PwrGood 50 * 2 milli seconds
bHubContrCurrent 0 milli Ampere
DeviceRemovable 0xe0
PortPwrCtrlMask 0xff
Hub Port Status:
Port 1: 0000.0503 highspeed power enable connect
Port 2: 0000.0100 power
Port 3: 0000.0503 highspeed power enable connect
Port 4: 0000.0100 power
Port 5: 0000.0103 power enable connect
Port 6: 0000.0100 power
Port 7: 0000.0100 power
Binary Object Store Descriptor:
bLength 5
bDescriptorType 15
wTotalLength 0x002a
bNumDeviceCaps 3
USB 2.0 Extension Device Capability:
bLength 7
bDescriptorType 16
bDevCapabilityType 2
bmAttributes 0x00000002
HIRD Link Power Management (LPM) Supported
SuperSpeed USB Device Capability:
bLength 10
bDescriptorType 16
bDevCapabilityType 3
bmAttributes 0x00
wSpeedsSupported 0x000e
Device can operate at Full Speed (12Mbps)
Device can operate at High Speed (480Mbps)
Device can operate at SuperSpeed (5Gbps)
bFunctionalitySupport 1
Lowest fully-functional device speed is Full Speed (12Mbps)
bU1DevExitLat 10 micro seconds
bU2DevExitLat 231 micro seconds
Container ID Device Capability:
bLength 20
bDescriptorType 16
bDevCapabilityType 4
bReserved 0
ContainerID {63736d73-7835-7878-0000-002c11095b74}
can't get debug descriptor: Resource temporarily unavailable
Device Status: 0x0001
Self Powered
Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Device Descriptor:
bLength 18
bDescriptorType 1
bcdUSB 2.00
bDeviceClass 9 Hub
bDeviceSubClass 0
bDeviceProtocol 0 Full speed (or root) hub
bMaxPacketSize0 64
idVendor 0x1d6b Linux Foundation
idProduct 0x0002 2.0 root hub
bcdDevice 5.04
iManufacturer 3 Linux 5.4.130-inmusic-2021-07-08-rt59 ehci_hcd
iProduct 2 EHCI Host Controller
iSerial 1 ff500000.usb
bNumConfigurations 1
Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength 0x0019
bNumInterfaces 1
bConfigurationValue 1
iConfiguration 0
bmAttributes 0xe0
Self Powered
Remote Wakeup
MaxPower 0mA
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 0
bAlternateSetting 0
bNumEndpoints 1
bInterfaceClass 9 Hub
bInterfaceSubClass 0
bInterfaceProtocol 0 Full speed (or root) hub
iInterface 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x81 EP 1 IN
bmAttributes 3
Transfer Type Interrupt
Synch Type None
Usage Type Data
wMaxPacketSize 0x0004 1x 4 bytes
bInterval 12
Hub Descriptor:
bLength 9
bDescriptorType 41
nNbrPorts 1
wHubCharacteristic 0x0009
Per-port power switching
Per-port overcurrent protection
bPwrOn2PwrGood 10 * 2 milli seconds
bHubContrCurrent 0 milli Ampere
DeviceRemovable 0x00
PortPwrCtrlMask 0xff
Hub Port Status:
Port 1: 0000.0503 highspeed power enable connect
can't get device qualifier: Resource temporarily unavailable
can't get debug descriptor: Resource temporarily unavailable
Device Status: 0x0001
Self Powered
It can be different on yours, because it's possible to forge usb devices with Linux Gadget modules ( google it ofr more details)
Good luck :) :)
-
On my side I own a MPC Akai Force with a customm Firmware allowing to connect on the SSH.
Here is what the lsusb -vvv describes about the USB bus topology on that board (although order within each vertical segment is unspecified):
RK3288
│
├─ Bus 001 Device 001: USB 2.0 hub based on a DesignWare On-The-Go chip, uses standard Linux kernel driver
│ │
│ (no connected devices)
│
└─ Bus 002 Device 001: USB 2.0 hub based on a DesignWare On-The-Go chip, uses standard Linux kernel driver
│
└─ Bus 002 Device 002 (09e8:5040): AKAI Professional M.I. Corp. Force Hub
│
├─ Bus 002 Device 006 (09e8:703b): AKAI Professional M.I. Corp. Card Reader
│
├─ (not connected to any device)
│
├─ Bus 002 Device 004 (13e0:2515): TSE Inc. USB Embedded Hub
│ │
│ └─ Bus 002 Device 005 (13e0:2517): TSE Inc. USB Mass Storage Device
│
├─ (not connected to any device)
│
├─ Bus 002 Device 003 (09e8:0040): AKAI Professional M.I. Corp. Akai Pro Force
│
├─ (not connected to any device)
│
└─ (not connected to any device)
The DesignWare chips are ubiquitous, and basically handle the On-The-Go functionality (fifth pin in USB micro connectors, telling whether this end should be the device or the host; the Linux side can use that to make the port either a host or a device using USB gadget drivers); very commonly used on SBCs where one or more ports can act as both host and device. This board has only two of them.
Bus 001 Device 001 is the first On-The-Go USB "hub", with just one port. That port is not currently connected to anything.
Bus 002 Device 002 is the second On-The-Go USB "hub", with just one port. It is connected to an AKAI-branded USB hub (Bus 002 Device 003), which is not listed in the Linux USB IDs list (http://www.linux-usb.org/usb.ids). I also cannot find the USB product number (5040 in hexadecimal, 20544 in decimal) anywhere in Linux USB hub drivers, so it looks like this hub also uses some proprietary driver that Akai is breaking the GPL license and copyright law with. Naughty, naughty. It does say it has seven USB ports, three of which are in use (first, third, and fifth), with the first two in high speed mode (480 Mbit/s), and the third in full speed mode (12 Mbit/s). Which one is which is my educated guess; the hierarchy is fully described under /sys/bus/usb/ but it isn't important enough to worry about here.
Bus 002 Device 003 is the full-speed device (09e8:0040) connected to aforementioned Akai USB hub, and is a MIDI controller based on its endpoints: three MIDI IN jacks, and three MIDI OUT jacks, and a couple of general (control) endpoints. Basically a simple USB-MIDI interface, in other words. (USB ID not listed in Linux USB IDs list, so who knows what driver this uses.)
Bus 002 Device 006 is a high-speed device (09e8:703b) connected to aforementioned Akai USB hub, and is a card reader. Again, USB ID not listed in Linux USB IDs list, so who knows what driver this one uses.
Bus 002 Device 004 is a yet another hub, this time one manufactured by TSE Inc. It has only one port, which is connected to Bus 002 Device 005, an USB mass storage device also made by TSE Inc. I do believe these two are either connected or even on the same actual chip, with the hub part controlling the power delivery and upstream connectivity, and the mass storage device being a standard USB mass storage device (Flash storage, perhaps eMMC, perhaps something else) using standard Linux USB mass storage drivers. The USB ID, 13e0:2517, has been seen on old 1 GB USB sticks ("Flashdrive 1GB").
What does this tell us about these devices?- The topology is indeed one where at least one of the DWC OTG ports is connected to a "nonstandard" multi-port USB hub, like I suspected.
In this particular device the hub is 09e8:5040, whereas jboy32 has 0763:0016. These numbers are unlikely to be spoofed, as they are usually provided by the USB hub itself, i.e. its own internal firmware. - The storage on this device is based on an existing USB storage chip seen on 1GB USB sticks.
These devices do not have particularly good wear leveling, so depending on how the filesystem has been configured and mounted, might wear out. - Akai uses USB hub drivers not in official Linux sources, and seems to use other USB devices they use their own USB manufacturer ID for, too.
This means that they have a custom Linux kernel tree to support those devices.
Not providing those sources for their customers is a violation of the GPL license. Because violating that license means they do not have a license permitting them to distribute the Linux kernel as part of their device, they are breaking international copyright law and agreements.
Naughty Akai, naughty.
The funny thing here is that the driver code really isn't something you want or need to keep "secret". Akai wins absolutely nothing, and actually loses a lot (of experience and help from volunteers like myself who habitually fix bugs just as a hobby for example), by hiding the kernel sources. Only the crappy developers who they commissioned the drivers from benefit from keeping the sources hidden, as that way their crappiness is kept hidden, and not derided in public. I wish somebody would hit them with a copyright lawsuit, just to whack the Akai ossified officers with a clue bat.
Note that there is nothing wrong in keeping the userspace code (the user interface et cetera) proprietary; that's theirs. But the kernel is not.
-
If you do want the actual tree, use lsusb -t (as root) to display the physical USB hierarchy as a tree.
Both of these, lsusb -t and lsusb -vvv are useful, but they do need to be listed separately. (That is, lsusb -t -vvv won't work.)
-
Hello,
Very interesting, i will do the command again soon because there is a sort of mux switch and when you change a certain value in a file, it will disconnect midi interfaces and allow the board to become a slave and to be seen as an usb drive when connected on a computer ( On these products : Akai/headrush/Denonprime, it's called " computer mode" ).
The cons is when we are in computer mode , all the midi controller ( buttons , controls , fader etc ..) are disabled or inactive.
(I am a bit deriving form the original subject :-// ).
Another thing i saw is that you can use usb gadget to forge fake devices, it seems to be used on these boards.
I'll post more details about later :)
-
Hey,i am also trying to fix some issues on my Denon Prime4, as it is out of waranty and ticket with support did not bring me to resolution....anyway, its uses exactly the same motherboard. but the issue i currently facnig is that debug port only outputs data, it does not allow me to interrupt a boot or use login prompt after its boots....so just wondering did you needed to do anything special to get that working ?
as on u-boot i see input says
"In: gpio-keys"
and only for out and err i have:
"Out: serial,
Err: serial"
so just wonder is that same on your one and did input worked out of the box or you need to do something special to make it work ?
Thanks
Best regards,
Domas Zelionis
-
Hi everyone
My board is in a headrush gigboard.
The debug port have 6 pins but none are spotted.
Someone could heplp me please?