Jump to content

jock

Members
  • Posts

    2075
  • Joined

  • Last visited

Posts posted by jock

  1. @speed21 Well I don't have experience with OMV in docker, I run mine on the bare operating system without issues, but actually I don't know if installation scripts have been adapted to OMV6: you could try to install it from armbian-config if you don't worry about having it outside docker, or you can try and run your own container but that may take some time...

     

    edit: your MXQPRO_V71 Is very very similar to mine MXQPRO_V73, which is very well supported with the proper led-conf overlay, you should have no particular issues with the hardware.

  2. @MR01 Yes of course you can, you should try to investigate ir-keytable utility that should help you receive the raw scancodes, in particular the -t flag to do testing.

    Usually one of the common protocol is NEC (practically all tvbox remotes use the NEC protocol), but you may have to guess it in case it does not work with your smartphone, which usually is software programmable to emulate several devices.

  3. 3 hours ago, speed21 said:

    Hello, @jock I flashed armbian bullseye on my tvbox with emcp and it works fine. now I am having problems  running this thing headless. I installed OMV6 and every time I try to fire up the box without plugging in any display the OMV crashes. I can't log in nor do anything to it but I can ssh the box. I bought an hdmi dummy plug to try if it works but it still crashing.

    Hmmm, I did not understand if the board crashes or OMV becomes unresponsive (and which part, since OMV leverages nginx and php for the web admin and samba/nfs/ftp for the file serving services).

     

    You say that you can "ssh the box", but you mean that you can login via ssh and the board still operates normally or the ssh service is apparently responding but you can't login?

    I have a board with debian buster that is running OMV perfectly fine for several months right now, but also I'm experimenting with an eMCP board that has Home Assistant and running as wireless AP without any issues. Both of the board are running headless with no problems or crashes. The eMCP board is a MXQPRO_V73, should not be far different than your MXQ_V71 (I may guess it is a MXQPRO_V71? You could post some high resolution photos that may be helpful identifying the board and its components)

  4. @r00tl3ss

    Hello, the answer to your question is "yes, but depends".

     

    Normally you're in the perfect condition to boot from sdcard: the emmc is not recognized or has and invalid bootloader, so the SOC tries to boot from sdcard. You should be able to boot anything (except Android) from sdcard: armbian, libreelec, multitool or whatever...

     

    You're both right either about completely desoldering the emmc and shorting the clock pin: shorting the emmc clock pin should be enough to mask it from the soc and desoldering should not be necessary.

     

    Now comes the bad news: unfortunately if you're not able to boot from sdcard in your condition, I'm afraid the sdcard slot is wired to the "alternative" (also called sdmmc_ext) controller and not the usual one. The SOC, as far as we experienced here on the forum, does not look for alternative controller during its very first boot phase. It turns out that, on those boards like yours, it just does not see the sdcard because it is not wired where expected.

     

    If you have the serial uart attached, you could post the output you get when you run rkdeveloptool db your_loader.bin from your computer. Maybe it has some hints about the emmc or sdcard controller. Also be sure to get a loader which is recent or up to date; if it is too old it may not detect the emmc correctly.

     

  5. Hello @fr3d, last day I checked in with my tinkerboard-s and a fresh Ubuntu Jammy cli image, kernel 5.15, taken from download pages.

    Everything was working very fine with my router, which is crappy sercomm but does its job.

     

    What I noticed is that the power management of the chip, which is on by default, may interfere a bit and caused some up&downs in throughput.

    You can try to turn it off with:

     

    iwconfig wlan0 power off

     

    Also the transmitting was kind of low (12db); I don't know where is the programmed default, but you may try to increase to near-maximum and see if you still have problems:

    iwconfig wlan0 txpower 18

     

    To show the hardware settings (including power management and tx power):

    iwconfig wlan0

     

    Try and tell me if it gets better

  6. 7 hours ago, im_chc said:

    I thought I had bricked it, but I wonder if there's anything to do with it? 

    I didn't expect to run Armbian on it, but if I can ssh into it and run something like lighttpd, it will be already great

    You can try and follow the "Restore" paragraph on the first page.

    It shows how to manually upload an image to the internal flash without using the multitool but just the basic maskrom mode.

     

    But from the photos I see that your stick has a SPI flash memory.

    It has never been tested and I don't think any image could even boot there because both u-boot and kernel must be aware of that hardware, and in current images they aren't.

  7. 6 hours ago, Aapo Tahkola said:

    I'll check the original firmware once I get H96 MAX 4gb. Do not wanna risk downtime on PiVPN(which works fine BTW once you figure out the fw kinks) and HA. I did pay premium for the 4gb and there is a little "4GB" sticker inside so I am leaning towards ddrbin having some issue. Does this ddrbin have sources, named author somewhere ?

    Perhaps you did not pay attention to what I already wrote several times, so I highlight a bit it here: the ddrbin is a proprietary code from rockchip with no public source code.

    I don't see any value in checking the original firmware on a different board, that's your precise board that is having issues, other boards are known to work well even with 4GB of RAM.

  8. Hello fr3d, I recently tried the Tinkerboard-S (which should be identical to yours, except for the onboard eMMC) for the imminent new armbian issue release and, despite the network was far from being fast, I was able to connect without particular issues to my router which is one floor away with basic WPA2 encryption. My test image was Jammy with linux 5.15 kernel, so it was pretty regular. Which image did you use?

     

     

     

  9. 2 hours ago, speed21 said:

    after contemplating on installing armbian, I finally managed to do it and it boots on first try but only in sd card. I'm kinda scared to flash it to the internal memory and mess up the box because it has emcp. 

    If the armbian boots from sdcard the worst thing that may happen, once installed on eMCP, is the rootfs that does not get recognized. It is not as scary as it may sound, because you will indeed be able to reboot from sdcard into armbian/multitool.

    I think you're safe enough.

  10. 13 minutes ago, donluca said:

    At this point I'm a bit scared to proceed and try to wipe the eMMC since I can't test Armbian by booting it from the SD card 😐

     

    Normally all the other board works that way because that behaviour is embedded in the SoC, but I don't know if the manufacturer did some weirdness with your board and that does not apply to you, but if you wipe the emmc the board should boot from sdcard, and then armbian can boot.

     

    What is preventing armbian from running from sdcard is the android firmware, if you remove it from the emmc then both armbian and multitool should boot fine from sdcard.

     

    edit: ha, I just reread the post and got the thing about the multitool green screen... well that's a very good sign, that means there is something not exactly right for your board in the dtb or the kernel. Do the led is fixed on/off or it is blinking? The serial adapter may tell more about the crash.

     

  11. 27 minutes ago, donluca said:

    Looks like this board doesn't like booting from the SD.

    I've tried booting both Multitool and the latest Armbian image and both time it just booted into Android.

     

    When powering on while keeping the uboot button hidden in the AV connector it just doesn't do anything, black screen.

    Yes, when you push the button you can then use rkdeveloptool to erase flash or upload a new firmware to the board, but you need a male-to-male cable to connect your PC to the OTG port of the board.

    There is some reference about in the first page of the forum on how to do that.

     

    The Armbian image as-is is not supposed to boot from sdcard if there is the android firmware, but the multitool should boot from sdcard no matter what firmware is there.

    Well you can erase your flash if you don't care about the original android firmware; then the board will boot from sdcard in any case, but still your case is a bit weird because usually the multitool boots fine.

  12. 51 minutes ago, marras said:

    @jock at the end I was impatient and I cleared the emmc and tried to restore the backup... Everything went well, Android has been restored successfully! I think I was lucky because the backup is 2.5gb, under the fat32 limit, but after decompression it is as big as the all emmc (16gb). The problem is that I cannot extract anything from it, since the decompressed file is not an archive according 7zip, it's just a file without any extension. After cleared the emmc again, Linux from sd booted successfully and also after flashing in the emmc. wifi, hdmi works (only audio doesn't but I don't need that). I'm a bit disappointed by the performance, xfce doesn't run that fast, but it's ok since I need just to install klipper for my 3d printer and I hope it's enough for this purpose. Thank you for all the support, you have been precious!

    Ah ok, not I got it... you tried to decompressed the backup twice, and the second time came the error. Well that's right, once you decompress the first time, you get a binary image that indeed cannot be decompressed again. You need a specific tool if you want to extract anything from it, but as long as your board boots and works fine there is no need for the dtb to be inspected.

    The performance is what you get from an old armv7 chip, it has no horsepower to be a complete desktop replacement but works really fine for server/command line tasks.

  13. 2 hours ago, donluca said:

    Still, I'd feel more comfortable knowing if there's been any test done on this board.
    I don't need video output or anything else as this is going to be the DNS server of my local network (Pi-Hole, DNSCrypt and all that jazz), but I'd really appreciate not having to sacrifice an SD to hold the rootfs and, more importantly, the ethernet MUST work.

    Normally the base dtb shipped with armbian should work fine with all boards out of the box.

     

    Since your board looks very similar to MXQ_V72/V73, you may also try to apply the led-conf for that board via rk322x-config, but actually you can also keep the base dtb if your board is stable.

    The wifi chip is not supported in mainline kernel, only the ssv6051 works; there is an adapted driver but you have to compile it by yourself.

    Ethernet will work out of the box.

    Anyway a dmesg log can already tell if the peripherals of the device are all detected or not, but for your tasks probably it is much more useful to see if the eMCP flash supports DDR or HS200 modes.

     

  14. 8 hours ago, donluca said:

    and wanted to know if this is still the case, even with the nightly builds found at https://github.com/armbian/community

     

    Thanks for pointing it out, I'm going to remove that warning!

    I had the chance to test some boards with eMCP (notable the MXQ_V73) and they now are quite well supported.

    I don't know which board you have, so apply the general precautions before flashing into the internal emmc.

  15. 8 hours ago, marras said:

    Anyway, the 2 backups seems the same, how can I extract the files and dtb from them? I tryed 7zip but it doesn't not recognise the file inside img.gz as an archive so I don't know how to extract

    Ah ok, so your backups are not good. Unfortunately there is a huge bug in multitool due to FAT32 partitions: the files cannot be bigger than 4GB. The multitool will say the backup is ok, but in reality the file is broken because it is truncated to 4GB by FAT limits, despite being compressed.

    At the moment there is no easy solution for this, both using NTFS partition or split program have some drawbacks and this bug is still not fixed yet 😕

     

    You may altough try to do a backup via network, since you have ssh access.

    Do this on your PC:

    nc -l -p 1234 > backup.img.gz

     

    Then login in the multitool and run this:

    pv /dev/mmcblk1 | gzip | nc -N your_PC_ip 1234

     

    The commands will transfer the content of /dev/mmcblk1 (which should be your emmc, double check with lsblk) via network using netcat to your computer (change your_PC_ip with the right IP address) and you will get a full and compressed backup in backup.img.gz file. The pv command is handy because will tell you the progress of the operation.

     

    An alternative is to restore Android factory defaults and try to backup again. Maybe without the user content you will be able to shrink the backup size.

     

    8 hours ago, marras said:

    edit: reading carefully the guide, you suggest to wipe the flash first, than try to boot from sd card with armbian flashed onto it, and then if everything works try to flash in the internal memory, right?

    Yes, that's the correct procedure.

×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines