jock

Members
  • Content Count

    420
  • Joined

  • Last visited

 Content Type 

Forums

Member Map

Store

Crowdfunding

Applications

Calendar

Everything posted by jock

  1. Hello. Yes, there should be the chance to boot from USB stick. First I want to apologize because after a recent discovery I get aware that doing rkdeveloptool ef on a NAND device also removes the bootloader. Due to the NAND peculiarities, tooling around with that piece of software makes further restore of the firmware very difficult. I just updated the first post with new instructions, there is the Jump Start procedure for those who own a box with NAND flash that will install the bootloader into NAND to let SD Card and USB stick boot. You may give it a chance.
  2. @MMarcio MMhhh, I just noticed that your internal flash is a NAND too. Sorry but the same limitations applies to you and for now you are limited to external sdcard
  3. @MMarcio @nokirunner Here we are, here there is the first version of the Multitool. That's an image to burn on an sd card: plug it into the tvbox and it will boot allowing backup, restore, erase and image burn on the internal eMMC. To burn armbian/libreelec images directly to internal eMMC memory, place the compressed images into images folder of the sdcard and use the relative function of the Multitool. Any feedback is welcome! @Mark Khevin Rogacion I'm sorry but your box is unlucky to have a NAND chip instead of more common eMMC memory. Since there are no open drivers for rockchip nand, there are limited functionalities (like no kernel/uboot updates) and putting the rootfs on the NAND still require manual working. Me and @fabiobassa are working on a way to let armbian installation work the best, but at the moment you should stick to external sdcard.
  4. Windows? You could either run armbian-config to transfer the system from the sdcard to the emmc or use rkdeveloptool to write the image directly on the emmc.
  5. Glad to hear it worked for 6 days. Unfortunately that's hard to say what went wrong: logs seems ok and I can't see any specific trace of what happened. At the moment no extensive endurance tests have been done so it's a completely unknown territory. But any feedback is very welcome.
  6. What board do you have? Did you run rk322x-config to choose your board? What happens if you do modprobe ssv6051? Post the dmesg log here
  7. They remain because they are not partitions but devices. Could you post the results of mmc extcsd read /dev/mmcblk2 here?
  8. It is very important that you plug the male-to-male cable in the OTG port of the box. All other devices must be disconnected, sdcard slot must be empty and the power cord must be disconnected. You may try with and without pressing the button behind the AV connector. Anyway you can do an alternative procedure to clean the eMMC: download an image from those provided by Maker39 in this post, the smallest one will fit perfectly . burn the image on an sdcard plug the sdcard into the box power on the box an armbian installation should boot, you should be able to login with default credentials (username: root, password: 1234) - beware: don't try to install this image into the eMMC or you will brick the box! run blkdiscard /dev/mmcblk2 and wait a few seconds, when done the eMMC is clean! shutdown the box at this point download your preferred armbian image from the first post, burn it on the sdcard, plug the sdcard in the box and power on. You should get into the fully-featured armbian installation and you can also use armbian-config to install it in the eMMC.
  9. Those hardware partitions are part of the eMMC and are available to contain "alternative" boot code. I never played with them, they could in theory be exploited for some useful purposes, but AFAIK no board uses them. I think you can ignore them, on my boards they are all empty. I don't really know what to tell you. You may try with blkdiscard /dev/mmcblk2 that is the proper way to erase the eMMC.
  10. The procedure is described in a bunch of simple steps in the first page of the thread. All you need is just a male-to-male USB cable and rkdeveloptool binary. Linux is not absolutely needed (rkdeveloptool is available also for Windows, but don't ask me where) but is really really suggested. AFAIK, nope It used to bypass the eMMC/NAND (your board has an eMMC), in fact shorting that ping you are clock gating the eMMC/NAND device, so the processor thinks there is no eMMC/NAND device at all and tries to boot from the external microsd card. If also there isn't any microsd card, the processor puts itself in MASKROM mode, which is a sort of maintenance mode accessible from a PC connected to the OTG USB port using rkdeveloptool. If you can't write on the forum, write me or @fabiobassa in private.
  11. Sorry I missed the commands. Now I fixed the post
  12. @nokirunner Try these instructions, they worked perfectly well for me on two different boards, including the clone of yours. I suppose your eMMC is empty, if not erase it the way you prefer. Download this binary: rk322x_loader.bin in your rkdeveloptool directory Detach all the cables from the box Attach the male-to-male USB cable to the USB port near the HDMI Attach the other end of the USB cable to an USB2 port of your computer. Now with lsusb you should see 2206:3206 device listed. run sudo ./rkdeveloptool db rk322x_loader.bin, it should finish in less than 5 seconds run sudo ./rkdeveloptool wl 0x0 image.img, where image.img is one of your preference taken from the first page of this thread (others will just not work). Wait until done, then detach the USB cable and you're done This works perfectly for me
  13. Both rk3288 and rk322x now works fine with kernels (5.5 for rk3288 and 5.6 for rk322x) compiled without VDSO. Chrony still is not able to start, so it is not related to this one: uninstalling it via apt, systemd automatically resorted to systemd-timesyncd which immediately synced with remote NTP server.
  14. I made a strace of date utility and got this: Now I don't see any clock_gettime, but there is a syscall_0x193, of which I found some references here. I'm compiling a kernel with vDSO disabled just to see what happens. It could be it is affecting 32 bit arm (rk322x and rk3288), but not 64 bit arm (@Werner Opi1+)
  15. I assure you won't be happy about that image, I just made it for private testing because there is a very nasty bug (probably in glibc) we are investigating here
  16. Possibly, I just build for rk3288 and kernel 5.5.17: I don't have the system time jumping around, but still many systemd services have issues, don't start or keep failing. e2scrub_all and fstrim seem to be particularly affected. Running systemctl alone to show the services often instantly fails with "Failed to read server status: Connection timed out". edit: I correct myself, system time is jumping around also on rk3288
  17. @jeanrhum any news about the eMMC? I had the chance to build a new armbian image with Ubuntu Focal and kernel 5.5.17, and on my machine the eMMC is right there. Did you also try the "official" build from armbian download page? It's a 5.4 kernel, so comparable to your build
  18. Yes sir! It looks like this is the cove of the quarantined people, never seen so many italians on the forum Good catch, it looks very promising. I did not see that post before. but I will try to compile as soon as I can! Sure, just ask about anything!
  19. Hmm guys, I'd like to say that you should stay away from Ubuntu Focal with mainline kernel images for now. This applies to people who downloaded the image in the past, because at the moment I didn't propose one in the first page. There is a very strange issue with the system time that makes the image not work reliably. I opened a new thread about because at the moment I'm clueless about.
  20. I'm experience a really weird problem on a very experimental setup: the system is an Armbian build for an unsupported board (Rockchip RK322x) and Ubuntu Focal 20.04 with mainline kernel 5.6.4. The system has issues to boot when enters into systemd: it is slow but all of sudden it goes farther. Many different systemd services are complaining, expecially the journal and the chrony NTP client. Finally I found that the root of the problems is the system time which is abruptly moving back and forth even by months. Subsequent calls to date may report 20 June, then 4 March, then 18 August and so on... The kernel log is fine and, most of all, the very same kernel works perfectly with Debian Buster 10 and Ubuntu Eoan 19.10. Also Ubuntu Focal 20.04 works fine using the legacy rockchip 4.4.194 kernel. I also booted from a clean Ubuntu Eoan 19.10 and then upgraded to Focal via apt; the problem manifested the same way, but I got some logging errors telling me that an assertion failed on clock_gettime() system call, which does not returned 0 as expected. All the installations were Armbian Minimal, so no GUI or advanced services whatsoever. Any ideas?
  21. @Maker39 The problem with power-on with remote is that the box is... powered off! The original firmware does never really shut the box off, but keep it in suspend state in u-boot, u-boot "listens" and then is able to react to remote power key and trigger the bootstrap. When you shut down in armbian or libreelec, the box is really powered down, so you need to do a full power-cycle. I didn't investigate too much into this problem, but this is a very common problem on most boards on different platforms when you switch away from original firmware.
  22. You disguised very well I would have said you were American, or Mexican Nope didn't experience anything like that, but I will definitely check. Which image are you using? In the meantime, could you run openssl speed -multi 4 rsa and post the summary results here? It's just an openssl benchmark to compare performances.
  23. I'm getting a bit suspicious about this ssv6x5x driver, which does not appear anywhere in rockchip source code. Maybe our ssv6051 is a stripped down or older release, or just an incompatible driver with 62xx series, despite it is heavily based on
  24. My guess is that ssv6051p and ssv6256p share the same driver. Looking into the code I see no reference about ssv6x5x file name at all. This is the dmesg messages related to ssv6051 module with ssv6256p firmware: as you see, at a certain point it says something about a register not containing the expected value and then reports errors
  25. @nokirunner yes, most probably it is the right firmware file, but for some reason the last time I tried it didn't work. The driver is not very helpful in describing what is wrong, just fails with a bunch of cryptic debug messages and so. But I guess I can give it another chance!