jock

Members
  • Content Count

    420
  • Joined

  • Last visited

 Content Type 

Forums

Member Map

Store

Crowdfunding

Applications

Calendar

Everything posted by jock

  1. I didn't try to compile Kodi yet, but instead I did a quick test using the packaged one from Ubuntu Focal, which was 18.6 if I remember well. It starts, I get to the splash screen, but then it hangs the board and can't even change to another virtual terminal.
  2. I'm interested in lima too. At the current moment on libreelec it works very well on different platforms (rockchip, but also amlogic, don't know about allwinner but I guess it works fine either). On my armbian builds here, i don't know the reason why, it fails both in running X11 (which can be expected), but also Kodi without the X server, which in theory is the same configuration as libreelec.
  3. Seems a pretty interesting project. Good luck for that! Unfortunately the keep costs down, tv box makers use chips from unknown and unreliable sources, then happens that the vendor failed (at least rumors say so) leaving us with a very badly written driver. That is one of the reasons why I avoid cheap tv boxes when doing serious pet projects, a proper single-board-computer is much more suited. As @fabiobassa said, ssv6051p driver is suitable for ssv6256p also, but for some reason it does not work.
  4. Yep I totally misunderstood
  5. @nokirunner @Maker39 As far as I know, the only programming USB port should be the OTG port. Sometimes it is labeled on the PCB, sometimes the enclosure has the OTG label, sometimes there is nothing telling you which port is the OTG one. For example, the Scishion Model X (the same owned by @nokirunner) I got here has 2 USB ports, none of them is labeled OTG in any form and they are both labeled as "USB" on the chassis without any number on them. Other devices, like the MXQ Pro 4K has the OTG signature on the PCB corresponding to the USB 4 port labeled on the chassis. So it's a bit of hit and miss, but finding first the OTG port looking at the board can avoid many headaches later
  6. in maskrom mode, before doing executing any command, you must upload the loader. rkdeveloptool db command may come in handy, you can see how to use it on the first page in the "Restore the firmware" section. But I would say it is far easier to just boot into linux. Just plug the sdcard into and boot with the eMMC shorted. Remember to unshort as soon as you see the red led.
  7. I hope you didn't damage the eMMC. It could be that the eMMC is not available because you shorted the eMMC clock pin at boot. Shorting the eMMC to ground makes it unavailable to first stage bootloader. Keep us informed about progress.
  8. @nokirunner sorry but I don't have ever used that tool so can't be of any help.
  9. Hello, sorry for replying so late, but didn't get the mention from your previous post. The service file you quoted in that post contains the systemd service that activates the bluetooth userspace service. It contains the invocation to hciattach /usr/bin/hciattach /dev/ttyS0 bcm43xx 1500000 that will create the bluetooth device for use of other applications. First you need the firmware file in the right place. Unfortunately hciattach is a legacy program, it wants the firmware file in /etc/firmware, so: create the directory with mkdir -p /etc/firmware symlink the firmware wth ln -sf /lib/firmware/brcm/BCM4330B1.hcd /etc/firmware At this point I suggest you to do some tests using hciattach command above. You may need to modify the command line because /dev/ttyS0 device is the serial device the bluetooth is attached on rockchip boards. You should first find which is the UART the bluetooth is attached to on your board. Be sure it is active in the device tree (so it is exposed as /dev/ttyS* file in the filesystem) and then change it in hciattach command line above. Use hciconfig -a to see if the device is exposed to the system and hcitool scan to scan for bluetooth devices. Once you have found the right serial device: modify ap6330-bluetooth.service to use the right serial device copy ap6330-bluetooth.service file in /etc/systemd/system to make systemd aware of the new service, run systemctl daemon-reload to make the service run at every boot, run systemctl enable ap6330-bluetooth You can find the references in armbian scripts of above steps here
  10. @nokirunner Very glad to hear you brought the board to life again
  11. @nokirunner I got an identical board to yours here, thanks to @fabiobassa I can show you the eMMC clock pin. There is a small white circle in the upper left angle of the eMMC chips, that's the pin 1 of the eMMC. The eMMC clock pin is the 7th starting from the top on the other side. Now in this photo @fabiobassa soldered it for me, because he is much more experienced. Before proceeding any further please answer the question on the previous post and burn an image provided in the first page of this thread on your sdcard and check if it boots. If does not boot remove the power, and try to short the clock pin using a cross-headed screwdriver: push the head of the screwdriver with a bit of force (but not too much) between the 7th and 8th pins to connect the two pins. While you're shorting the two pins, attach the power cord, then remove the screwdriver. If the procedure went well, the red led should become very bright after a couple of seconds and after 15 seconds the blue led should start blinking. If this does not happen, power off the board and try again. I just tested this on my board and it works.
  12. @nokirunner I'm really sorry this happened Everything seems odd to me, beginning from the unusual USB device ID, sdcard allocated to mmcblk1 (it should be mmcblk0) and now this unexpected brick. 1. Did you use the images provided by @Maker39 or those provided by me on first page? If you used one from Maker39, try to burn an image provided by me, put the sdcard into and boot again. 2. Did you run armbian-config and followed the instructions to install in internal eMMC or you did install in another way? 3. Did you run the hexdump command I suggested you in the previous post (here) ? It was useful to understand if you really got an rk3229, because that USB device ID is suspect.
  13. Did you blacklist 8723cs module to let rtl8703bs work? The MAC address unfortunately is still an open problem, it requires further attention but I haven't any board with 8703/8723 chips to test This is strange. Are you using original images or those "cured" by you? I suspect that if you're using the cured you have to change the device tree manually creating the resource.img file from the device tree and put it in the right partition. Also can you post the whole dmesg output.
  14. Can't you just backup /dev/mmcblk2 from armbian using dd? I have absolutely no experience with encrypted/secured devices because I never got any in my hands and I don't know what happens if the internal bootloader is wiped out here. Maybe @hexdump can give some advice. Also, could you please post here the result of this command: hexdump -C /sys/bus/devices/rockchip-efuse0/nvmem
  15. That's a question I can't answer for sure, since I don't own any S905X3 devices. My experience on amlogic is limited to S905 soc and I can confirm that the "draconian" approach works: once you erase the eMMC (or ground the clock pin of the eMMC chip), it will try boot from the sdcard. Most probably nothing changed with later chips, since this seems to be the common behaviour among various chips and vendors too, so my answer can be "probably yes"
  16. All the images in the first page have been updated with the following news: Single image for all boxes! Configure your box with sudo rk322x-config once the system has booted Support for Realtek 8188eu, 8189es/etv, 88x2bu and various other wifi chips General better stability eMMC in DDR mode for some boards Enjoy!
  17. Yep, I'm finalizing the process of migrating all the boards into a single image, you should be able to find the board rk322x-box in the list if you want to compile. Tomorrow I will upload new images and new instructions.
  18. @hexdump But that's exactly the point I want to highlight: those little differences and customizations of some unlucky boards make thinking about a framework hard and maintaining it even harder.
  19. About VPN, currently there are much more opensource-friendly VPN alternatives, OpenVPN is de-facto standard nowadays and it available for linux, windows and macos. If you need a stable solution, you may try it out. Armbian also has support for wireguard, which is one of the most exciting VPN recently merged into linux kernel due to being very fast and secure, and it is ideal for embedded devices. About the 2GB partition size, normally armbian enlarges the partition on first boot to fit to the device size. You can, however, do it yourself enlarging the partition and then using ext4 standard tools to adapt the filesystem. It's a matter of seconds and there are plenty of tutorials on the internet on how to do that.
  20. Speaking personally, my efforts in supporting tvboxes in armbian basically starts from treating them like other SBCs. From my point of view they are just boards like any other. This is not entirely true because SBCs have specifications, the components are always the same or at least compatible, and they usually received some quality assurance - with some clamorous exceptions. Tv boxes wildy change hardware for the same commercially named product, which makes supporting them a nightname. But forgetting for a moment the confusion around tv boxes hardware, what you ask is not so far away in my opinion, and does not require changes to armbian ecosystem. On the contrary: it requires changes to the user expectation. The user expects that she burns the image on a sdcard, put the sdcard in the box and everything just works. Currently for many images proposed in this forum section, it is so. It just works, but has its constraints: the system lives outside the armbian ecosystem, so don't expect to get the all the armbian ecosystem gifts and goodies, kernel updates on top of that. Technically speaking, armbian puts together several parts which are expected to work with each other. The focus is on mainline u-boot and kernels, and proprietary blobs and kernels are kept as last resource. To make tv box images work out of the box, you have to sacrifice the first step of openness: you need to exploit the proprietary bootloader already installed on your tvbox, specifically u-boot. Proprietary bootloades wants proprietary ways to load the kernel, device tree binary, root filesystems, and so on... So it happens that when you upgrade the kernel someone should take care of converting the kernel and other parts to make them compatible with the proprietary bootloader. But should armbian people take care about the proprietary u-boot installed on your tv box? I would say no, they absolutely have not to. And that is even more true if you think that mainline u-boot just flattens all those differences between proprietary software, so why keep using the proprietary bootloader? My personal approach is draconian and requires a bit more work for the user: first step is erase your tvbox internal memory. After this, the tvbox ceases from being a tvbox and turns it into an SBC with internal flash memory. Without the constraint of the proprietary bootloader all the updates can be supplied - kernel updates included - without any change to the existing armbian code and ecosystem. You will notice that also the standard armbian-config tool will be able to install the system on the internal flash without requiring special scripts or procedures. In my opinion this is the way to go if you don't just want toy installations on tv boxes.
  21. Ok there's connman on current libreelec releases. Anyway with @fabiobassa I managed to do some tests on libreelec and 8723bs kernel module is not loaded at all, instead 8723cs and rtl8723ds modules are both loaded at startup and somehow the thing works. We are going to make some more tests and report here findings...
  22. @fabiobassa @Maker39 no iwlist and no iwconfig on libreelec try instead: iw dev wlan0 scan or: iw dev p2p0 scan
  23. @Maker39 I compiled a new "experimental" mx4vr image with 8189es driver, which supports also 8189etv, you can find it here Also you may get just the 8189es.ko module object from here and try to modprobe it. You may also try to modprobe 8723bs driver to see if 8703bs chipset is somehow supported, I saw some crossreferences in the code but no specific driver anywhere.
  24. Hello @willerson, at the moment I don't have any plan to support legacy u-boot, either because I don't really like the "messy" rockchip u-boot and also because armbian does not provide multiple u-boot, not to talk about having to maintain another device tree. There's a NAND driver for mainline kernel in the work at the moment, maybe in the near future we will have something available for mainline u-boot too. In the meantime you can use the method provided by @hexdump I linked to in the first post that uses libreelec boot parts.