• Posts

  • Joined

  • Last visited

Recent Profile Visitors

3219 profile views
  1. @Charles Bauer Apparently you did not read the first page carefully: Unbricking may be complicated, because neither me nor @fabiobassahad the chance to tinker with a board with eMCP. The problem is most probably related to memory initialization. A serial log is required for confirmation, but we already have seen a situation like that and I don't think this is different. Memory initialization is the first thing that is going to be done during bootstrap and thus, when it goes bad, the board is knocked down and requires manual intervention to get into maskrom mode. Doing this job require some skills in electronic and some non-common equipment because you need to find and ground the eMMC (eMCP in this case) clock pin. What you can do to help development is send the bricked board to @fabiobassa for him to analyze
  2. Stick with the autodetected (ap6334). Just follow the instructions in this last post:
  3. @curse I think I spot the issue: from dmesg I see that the brcmfmac driver is using the standard nvram file, but the standard nvram does not work because it is for BCM4334 and not for AP6334. This time I propose you to paste this file over /lib/firmware/brcm/brcmfmac4330-sdio.txt, reboot and try again. If the problem is that one, it is very strange because the driver is supposed to find automatically the right nvram file, it has always worked that way but for some reason this time does not.
  4. @curse I'm looking into the dtb and everything seems to be in place. I see that the dtb tells the wifi chip is ap6330, but rk3318-box detects ap6334. They are two different chips, could you please try to change wlan-ap6334 to wlan-ap6330 in /boot/armbianEnv.txt file? I see there are many clones here and there, maybe some cloned the wrong id. edit: photos of the board and logs (dmesg) are still particularly appreciated edit2: BTW the behaviour you are describing is often related to a wrong nvram. First restore wlan-ap6334 in /boot/armbianEnv.txt, then download this file and write over the existing /lib/firmware/brcm/brcmfmac4334-sdio.rockchip,rk3318-box.txt file. You may even try this other version to see if it works and/or has better performance.
  5. @curse Sorry for the late answer, but I just spot the post edit right now. wlan and bluetooth, despite being on the same chip, are connected to the SoC in different ways: wlan is connected via high-speed sdio bus, bluetooth via common UART; also they are physically different chip parts that just share some things (the radio part), so it may happen that one work and the other does not. Since rk3318-config correctly reports the right chip, it is attached to the right sdio bus. Now there there may be some board peculiarities that does not make it work. In the first post of this thread there are some good things that help in debugging, in particular if you can provide photos of the board and the original firmware or the original dtb I can inspect it and try solve the issue. If you can spot some marking/signatures on the board, you can see if there is a match in rk3318-conf when it asks for "led/gpio configuration". At the moment there are just two supported boards: YK_RK3328 (found on my HK1 Max) and X88_PRO_B ( @lucky62's box); maybe yours is a different one that require some minor adjustment to make wifi work.
  6. Yeah, you're right: the thread title is a bit misleading, because rk3318 and rk3328 are fundamentally the same chip. It is so because I have no rk3328 to work on, so can't guarantee and test anything on that. People reported that the images works as well on rk3328 boards, so you're invited to try and report if it works for you. There are good chances that the images works fine, and ap6330 is well supported in mainline kernel, including bluetooth!
  7. @RaptorSDS Thanks for the links! I will check ASAP. The board is giving me some stability issues and, among other things, the wifi and emmc are having troubles with mainline kernel. It looks like the pin configuration of the mmc controllers is somehow wrong, but need to check against the original dtb to be sure...
  8. Thanks a lot!! It looks like the board are exactly the same, probably they are clones of some sort: mine is labeled IPB900, yours T95N_RK3229. The external chassis has printed T95V Pro, fantasy names I can see that the components, power regulators and soldering pads (leds, serial, diodes, ...) are placed in the same position and the soldering pads. Can't remember if you already uploaded the original firmware or dtb, did you?
  9. Nope, we don't just need something that runs, we need the original firmware because only the original device tree can tell us the missing pieces
  10. Hello guys, this time @fabiobassa and me needs a bit of help We encountered the board you can see in the photo. It is from the Indian manufacturer AEMS and has the IPB900 marking on the PCB. We could not find the original firmware because it arrived with a badly flashed firmware. It looks like the board is a bit different than usual, so some things are not perfectly working and it is also overheating a bit: we thing we could arrange things a bit better for this board, but we need the original firmware or at least the original device tree. If anyone has this board and has the original firmware or a backup of the original firmware, it would be great if he/she could share to let us study it. The board seems to be one of the best in terms of performance for rk322x, so it is a pity if it could not be supported well enough. Thanks! ipb900_1 ipb900_2
  11. AFAIK there is no such tool for rk3188
  12. Where did you read you had to try dozen of combinations? Where did you download the image? If you paid attention to instructions, you would have been pointed to the right forum thread where other people could already have helped you.
  13. In the previous post you stated your box is an rk3188 box, this is the thread for rk3318. If your box is an rk3318, please provide as many as possible of the things described in the first post (logs, photos, original dtb), otherwise it is impossible to help. HDMI issues are common if cable is cheap, or the monitor less non usual resolution (like 1920x1200, for example)
  14. Of course it is opensource:
  15. Black screen after first reboot? Do you mean the thing solved by cpu-stability overlay? Note that the multitool is happy even if you put compressed gz/xz/zip/lzma/bz2 images in the images folder: it will decompress them on-the-fly. The FAT partition, right after flashing the multitool, should be a bit less than 2Gb. 800 Mb is strangely small