| Electronics > Repair |
| Trying to troubleshoot a main board with Rockchip RK3288 microprocessor |
| << < (5/7) > >> |
| coromonadalix:
Hum if i recall you have Rockchip tools (softwares) to format / install ose's / boot files etc ... 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 |
| jboy32:
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 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/ 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 :) |
| coromonadalix:
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 ? |
| Nominal Animal:
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. --- Quote from: jboy32 on January 10, 2022, 10:41:20 am ---at drivers/misc/usb5537.c:69/usb5537_write_config() ERROR: board_usb_init: failed to probe usb5537@2d: ret=-121 --- End quote --- 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. >:( |
| jboy32:
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 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 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/ @coromonadalix thanks for the links I will have a look. |
| Navigation |
| Message Index |
| Next page |
| Previous page |