Jump to content

jock

Members
  • Posts

    1809
  • Joined

  • Last visited

Everything posted by jock

  1. @Max Sterg No disturb, but please read the first post that will answer all your questions. PS: the specs of your box are totally fake, you don't have 8GB + 128GB eMMC, you probably have 1GB of RAM and 8GB of eMMC
  2. I understand; the problem is that those boards have some minor changes that makes them different than established boards. Maybe it is just a matter of tuning some little bits to get things perfectly working... I never stress enough that if you need something more serious, proper SBCs are the way, tv boxes are just for toying around and for those people that know perfectly how to work around in case they suddenly break because of the faulty components often they mount.
  3. Modify the img.xz to do what? It will be overwritten as well with apt upgrade anyway
  4. @SethI was inspecting an old dtb I have in my archive of a h96 max that someone posted time ago. Actually I don't know if it comes from the "rounded one" or the "squared one". I see that the one posted by @FRIKIdelTO has the RK3318_V1.4 marking and, searching through this thread, I see that also @kruzer had a h96max but on his photos the board marking is behind the heatsink. Anyway my guess is that SP6334, HY2734C, etc... are all clones of the AmPAK AP6334 which is, in turn, a combo of wifi and bluetooth chipsets from broadcom (BCM4334 for the wifi part, don't remember the name of the bluetooth chip). The driver is the very same broadcom driver that works fine for all the chips and the firmware is the very same. The only that changes is the "nvram" file, which is nothing more than the configuration settings of the firmware. Often, when you see the wireless network but can't associate with them, the problem is the crystal frequency that gives the clock to the wifi chip: the board mounts a crystal and the nvram says there is another one. @Seth do you have any photos of the boards? Or at least could you tell if both boards have RK3318_V1.x marking on them or are they quite different? It could just be that they are two different board from different manufacturers that have different internal designs. Also HDMI does work for you? As far as I understand, HDMI works for @FRIKIdelTO on this RK3318_V1.4
  5. AFAIK you don't need a specific driver for sata to usb bridges; they will just work as a generic USB mass storage device. You may need some special applications (like smartmontools) to know the bridge chip to send sata commands directly to the drive, but that's not something related to OS.
  6. Well, apart from making it read-only, honestly I don't know. It is part of the armbian firmware package and will get overwritten every time the package is updated. The reason I did not ship the alternative nvram for bcm4334 (your wifi chip is a broadcom bcm4334, 2734c is just a random name no one knows where it comes from) is that there is no easy way to switch from the "default" nvram to the "alternative" nvram.
  7. Yes: follow instructions on first post, in particular always test image on sdcard first! You did a bad mix: with this command you installed part of the proprietary bootloader/u-boot (which is in use on multitool but not on armbian) over the armbian installation, which does not use anything from the proprietary code. multitool should still boot fine, if it booted before it should boot as well after the mistake, I don't know why you get a black screen, but you may try to access it via ssh if you don't see anything on screen.
  8. Hello @rafaeldavid, thanks a lot, you're very kind! About the r29 board, yes as you noticed there are issues with that board. The HDMI problem is very well known and it is quite obscure, maybe some gpio has to be set to the right state but I wasn't able to find useful hints inspecting the device tree. The stability issues are very new to me, but looking at the board photos I see a bit of different design for the power section than usual boards. These differences may have some stability implications, but I'm just guessing. Another potential problem can be related with the Trust OS binary: during early development we noticed that the wront Trust binary could freeze the device after a predefined amount of time because it was triggering a sort of "sleep" mode, but the Trust (proprietary) binary now is working pretty fine for the vast majority of boards, so it would be quite strange that this is the offender. As you read in the other posts, this R29 board seems to be one of the bad ones and unfortunately I have no sample to study, so I'm very open to receive one sample. Recently I received a couple of rk322x boards from @Jason Duhamell and those were terribly useful to fix eMCP issues and support esp8089 wifi; having such R29 board on my desk to work with obviosuly increases a lot the chances to understand and fix those issues. edit: in the past we have encountered R29_MXQ boards, those may be a bit different than yours but the HDMI problem looks like is the same. You may try to apply led-conf7 from rk322x-config to see if stability problems goes away, but I'm afraid it won't really chance anything.
  9. This is the download page for Tinkerboard / Tinkerboars-S: https://www.armbian.com/tinkerboard/ Well, there is still confusion in your steps: If you want to write a full image (step 7) to the eMMC, you don't need step 5 and step 6. If you want to erase the flash and let the device always boot from sdcard, you step 5 is not needed Also when you do step 6, the device is not automatically in maskrom mode... it will enter maskrom mode when you turn it off and turn it on again! Remember that you are in real maskrom mode when you first need to run rkdeveloptool db command. This is not exactly "activation" of the bootloader. ul means upgrade loader: it will write the bootloader on the eMMC in the famous first 0x2000 sectors. Although it is very harmless to run the command after db command, you don't really need ul if you're going to erase the internal flash right after with ef command. You also don't need to do ul if you're going to burn a full image, either taken from multitool backup or a pristine armbian image. I'm sorry about the confusion, but it is so because the instructions on the linked page assumed that you are going to do a manual backup in rockusb mode (that will skip the first 0x2000 sectors), and then restore in maskrom mode. Multitool came much later than those instructions, I left them there for reference. Multitool is the preferred way to do backup and restore because has no limitations and indeed is much easier to use.
  10. Extensions have no meaning in the Unix world, you can even rename that file with a ".exe" extension but it does not change anything. What counts is the data in the file. The procedure requires that you first erase the eMMC with rkdeveloptool ef command; when done turn the box off, then turn the box on and you will be in MaskROM mode . Once there, follow the steps from "Restore backup" paragraph in the link above: you have to first use rkdeveloptool db command to upload a program to the SoC to program (no pun intended) the eMMC you can skip the rkdeveloptool ul command (it was necessary for manual backups, not for multitool backups) run the rkdeveloptool wl command Maybe the serial is switched to 1.5Mbps; some firmwares use 115200, some others use 1.5Mbps and may show you garbled data. On multitool and armbian by default I use 115200bps for compatibility. Yes, both of these behaviours are expected. The OTG port works as a power supply since it is supposed to be bidirectional. In fact when you do maintenance in maskrom mode you have not to connect the regular power supply but just the USB cable. Not all boards work this way though, but it looks like that both mine and yours behave this way. rkdeveloptool does not let you do anything with the box in MaskROM mode because you first have to upload the famous program with rkdeveloptool db I talked above. Once you do that, then you can use the other rkdeveloptool commands (including ef, wl, etc...) A lot of confusion comes from a fact: rockchip u-boot bootloader that is shipped with original firmwares, when stuck or when the reset button is pressed, provides the RockUSB mode, which is similar to MaskROM, but it is not the same! Unfortunately lsusb has no chances to recognize the difference and will tell you the board is in MaskROM mode, but it is not true. When you are in RockUSB mode, rkdeveloptool works without the bootstrap program because on the other side there is u-boot that is already answering. Another very very important difference between MaskROM and RockUSB modes is that the latter does not allow you to write the whole firmware: it will skip the first 0x2000 sectors, not allowing to overwrite the bootloader part, plus it will shift by the same amount the image you're going to write on the internal flash. Clearly this breaks everything, because partitions will not be in the expected positions anymore. To make the long story short: always operate on the internal flash when you're in real MaskROM mode. To get into real MaskROM mode you have to: erase the internal flash, or gate the clock pin with the screwdriver/whatever trick This is because the SoC on first instance tries to boot from eMMC. If it does not find a valid bootloader, then tries to boot from sdcard. If a valid bootloader is not there too, then stays there waiting in MaskROM mode waiting for an input from USB OTG port. No firmware/software has been loaded at this point, and that's the reason why you must upload the bootstrap program with rkdeveloptool db command before you can do anything else. Yes, this is the problem I talked you about the differences on the boards: the kernel is stuck somewhere because the device tree tells about a hardware configuration but your board has a different hardware configuration. If you burn the image on a sdcard, you can edit the file /boot/armbianEnv.txt and change verbosity=1 to verbosity=7 to let the kernel to show the whole log on the serial. This is of great help when you're debugging. You may also try armbian images for the Asus Tinkerboard-S, which has the rk3288 SoC as well and share many similarities. edit: you didn't say if you tried to just restore the backup with the multitool. Did you try? That's the easiest way to restore the backup...
  11. Q8 boards are those with "Q8" in the name. Mine is a xt-q8l-v10, but there are others like eny-q8l-v10 and so on... all of them are pretty similar in the board design. Yours has a different signature, R36 you say, and in fact it is somehow different from q8 boards. All the boards have the rockchip rk3288 SoC, but as I said in the post of the other thread, some differences may be so important that some hardware may not work (wifi is one of the best candidates), or even don't the let kernel or the board boot at all. It happens 🤷‍♂️ The error message is not really an error message. That file does not exists and should not exist, therefore I don't see any other message: it looks like u-boot got stuck there because I don't see the usual messages about mmc/sdcard probing for the kernel. Are you sure it does not progress further? Anyway, you can even try to burn armbian on the sdcard and let it boot from there to see if it works or not; of course if multitool does not boot probably armbian neither will, but surely worth a try. As last resort, you can restore the original firmware using rkdeveloptool (and just that one, not other tools) following these instructions; just be sure to unpack the backup before running rkdeveloptool wl command No, the board is not recognized as Q8. The board can't be recognized in any way from the software; instead u-boot is configured to use a stripped-down version of the device tree originally made for xt-q8l-v10. It should be generic enough to run on more rk3288 boards. If you're questioning yourself about the device tree, it is a file that contains the specs of the board hardware. Maybe you heard about ACPI/Plug and Play on x86 world, so the specs of the hardware are supplied by the BIOS to the operating system; in the ARM world there is no such thing like BIOS and ACPI, except on some server hardware. The specs of the hardware are described in a static and handwritten file given to u-boot and linux kernel, so they can know what is the hardware they have to deal with.
  12. Hello, I noticed the message on the Q8 thread yesterday and noticed this other thread here right now... one baby step after another I gave you some general hints on that thread (this post), but I guess it is more appropriate to keep the conversation here. From what I see from your logs, you installled something on the board which is a legacy android, if I understand correctly you still have the backup you took with the multitool and now you have this other rikomagic firmware installed which is not really working on the box. The backup took with multitool is just a raw gzipped imaged of the internal flash, I wonder what you intended with "the image was not recognized"; by whom? If the multitool is not able to recognize the backup image produced by itself probably the sdcard is faulty and the backup data is broken. Multitool should allow you to backup as well restore the backed up image. Surely if you want to use the backup in AndroidTool for windows or rkdeveloptool for linux you first need to unpack (I'm not even sure AndroidTool is capable to write a raw image). In the other post I mention to use maskrom mode to exclude eMMC and be able to use rkdeveloptool with USB male-to-male cable: rkdeveloptool can be used either to flash directly the backup image or erase the flash and let multitool boot again and flash image with it. Since the board is booting, it is possible that the multitool boots when you put in the sdcard and give power, but as long as the firmware you installed on the eMMC is not the original one it may not be true anymore.
  13. @Mierscheid sorry for the late reply, but I didn't notice the post. The image you installed is for another board called xt-q8l-v10, which is based on rk3288 but surely not the same board. This is quite important, because each board, especially "high-end" boards like this, have their own design and usually have a different Power Management Integrated Chip (PMIC). This is important because this little chip drives all the currents of the board, and if it is not configured right won't allow the board to work the right way. There may be other differences that may break things, so it is not advisable in general to burn an image directly on the eMMC without carefully testing it via sdcard first. The board can surely be restored to working state, but without UART logs is impossible to even guess where is the problem; surely bringing the board into maskrom mode (see this post) will allow you to use rkdeveloptool to erase internal flash and force the board to boot from sdcard (either multitool or directly an armbian image). I guess you already tried to boot the multitool from sdcard without success, this makes me think that the u-boot installed on eMMC has issues or does not even boot, which is bad enough to guess you need to bring the board into maskrom mode and do a manual intervention. The maskrom mode link I posted above is for rk322x, but actually it works exactly the same because eMMC chips have all the same pin layout. Once you keep the short the emmc clock pin to ground, you are "clock gating" the emmc and in practice it excludes it from the system just like there is no eMMC at all. When you unshort the pins, the eMMC will start working again.
  14. Interesting you found a way to put the device in maskrom mode, the testing points are not always obvious. I will link this thread in the rk3318 first post for future reference. However once in maskrom mode the board will boot from sdcard. As far as I remember, yours has the sdcard allocated to a "secondary" controller and for this reason probably is unable to boot multitool from sdcard when in maskrom mode. You could use rkdeveloptool to erase or program the internal flash manually when in maskrom mode with linux, or use the AndroidTool with Windows
  15. @Buqan Kaleng Kaleng seriously, I really don't understand what you're talking about. 🤷‍♂️ You said you can run multitool from sdcard, then erase the eMMC from multitool if you want to zero-fill the eMMC and zap anything. If you can't, the emmc is not detected and thus probably broken. There is no bootloader involved in hardware detection. From armbian you can run blkdiscard /dev/mmcblk2 to do the same the multitool does. Again: any error here means the emmc is not detected and probably broken.
  16. @Buqan Kaleng Kaleng I don't what you are talking about... if the multitool does not see the emmc, maybe it is just broken.
  17. @mkultra yes, you can now unhold the packages
  18. Looking at kernel dmesg I think it definitely has a problem: Sep 07 18:56:18 rk322x-box kernel: mmcblk0: error -110 transferring data, sector 520, nr 504, cmd response 0x900, card status 0x0
  19. @Krotosz6 Good you discovered it by yourself current and edge are kernel flavours. Current is the stable one, which is older but expected to always work. At the moment the current kernel is 5.15. Edge kernels are experimental/development. They are newer (at the moment 5.19) but can break anytime because they are not guaranteed to work, since they are... experimental! I don't have anything against tutorials, they are welcome, but the problem with them is that they become obsolete. In fact the apt-mark step is not necessary anymore, since support for rk3318 is now part of mainline armbian. The best tutorial is described in the first page of this thread, plus it is always kept up to date. Also images are now compiled and signed by armbian servers too, not anymore by myself - full instructions are again in the first post.
  20. @Krotosz6 Hello, indeed you're not seeing the internal memory: as long as the two pins are shorted, the clock of the internal flash is gated to ground: basically it does not receive any clock and that's the reason it is bypassed. You should short the two pins, turn the board on and then release the pins almost immediately. So far, even if the image installation has been interrupted, multitool should be able to boot anyway unless you wrote an image for another similar soc or you interrupted it so soon it was not able to write the bootloader. By the way, once armbian has booted, you should be able to see the internal flash as /dev/mmcblk2, thus blkdiscard /dev/mmcblk2 or dd if=/dev/zero of=/dev/mmcblk2 bs=1M count=32 oflag=direct should both be able to clean the existing bootloader on internal flash to let it boot again; otherwise you can use the multitool to do the same.
  21. @fukowaka You did not need to burn them on eMMC to test the mainline kernel images. Once armbian (any version) is installed on internal eMMC, it enables full boot from sdcard and USB stick too, so it is sufficient to burn the image to test directly on sdcard and plug the sdcard in the slot. Anyway you can increase the boot logging level changing verbosity=1 to verbosity=7 in /boot/armbianEnv.txt; this way the kernel w ill log much more informations and maybe will tell something intersting about the issue. Also you may add cpu-stability to overlays= line in /boot/armbianEnv.txt to see if the board boots. Also i have a question: do the mainline kernel images never boot, or they refuse to boot after you run rk322x-config?
  22. @Eliel Prado Taking a look at the log, it looks to me that your board freezes exactly after 60 seconds of operativity. it is highly suspicious, this kind of behaviour was often found when a wrong Trust OS (TEE) was in use, causing some kind of watchdog to trigger after a predetermined amount of time resetting or freezing the machine. The few garbage bytes on the serial just before rebooting were also typical about the Trust reboot thing. What is way more interesting is that the trust in use has been widely tested with a lot of boards and seems to work fine, but as long as it is proprietary binary code we don't know what does it do. I could provide you a special image with an opensource Trust and see if it works, but you have to wait a week or so for that (I'm on vacation right now...) Also it looks to me that you're using an outdated version of multitool, please try with latest version.
  23. @Neil WolfkidHello! You're a bit out of luck: if you want to use the legacy kernel builds you need to install the multimedia framework, which is unmaintained anymore and probably won't work on latest ubuntu versions (it was conceived for Focal). Mainline kernel builds instead have out-of-the-box support for 3D acceleration via Lima driver, and also hardware video decoding is supported in hardware (but in this case you may need specially crafted software - in few words: it does not work yet out of the box). In case you use mainline builds, you lose access to internal NAND: an experimental driver was brought up, but it happened it was not working as it was meant to.
  24. This makes me think you have some fake specs: rk322x cannot address more than 2GB of RAM and 4GB NANDs are pretty uncommon - never seen any rk322x with that amount of flash memory. Looking at the log dump I see 1Gb of RAM for your board. Anyway I don't understand why you are such an old image from 2020...
  25. @fukowaka glad to hear your board works fine. I suggest you to use a mainline kernel if you don't have a NAND, the kernel is way more up to date. Legacy kernel builds are very old and I just keep them for people with NAND boards. The eMMC tuning options (which obviously applies only to boards with eMMC/eMCP and not NAND) can give a consistent boost to eMMC throughput, but your mileage may vary.
×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines