jock
-
Posts
2075 -
Joined
-
Last visited
Content Type
Forums
Store
Crowdfunding
Applications
Events
Raffles
Community Map
Posts posted by jock
-
-
@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 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)
-
@MattWestB AFAIK rockchip devices don't look for USB boot as Amlogic instead do. I don't know if newer SOCs like rk356x or rk3588 do that, but for older SOCs USB boot it is not mentioned anywhere.
@r00tl3ss you have to select a piece of text and a quote popup will appear.
You may indeed try the cp210x USB serial, maybe it can reach the 1.5mbps speed even if it is not officially rated for.
-
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.
-
-
@Fathur Radhy that's because that board does not have an rk3229 but a allwinner h3.
Another fake spec is 8gb ram and 64gb rom: neither rk3229 nor h3 support more than 2gb of ram.
Probably your board has 1gb of ram and 8gb of flash.
-
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
-
On 11/29/2022 at 5:56 PM, Aapo Tahkola said:
I kind of think these bugs reports should go to kernel has bugzilla
This is exactly the reason why the linux has no bugzilla-like issue tracker, because people would abuse of that since this is not a bug of the kernel.
Please, stop posting nonsense.
-
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.
-
1 hour ago, Aapo Tahkola said:
Oh I totally missed the part of ddrbin being proprietary. armbian forum search functions do not work anymore so I could not search the old posts anymore.
The search function? It was two posts above yours: https://forum.armbian.com/topic/24085-csc-armbian-for-rk3318rk3328-tv-box-boards/?do=findComment&comment=153877
-
Thanks for reporting, that 5.19.15 kernel has LibreELEC patches in.
Unfortunately they were not accepted into mainline armbian, the 5.19 train is gone and I won't do all the rebasing work again for 6.0 or future kernels, so I suggest you to stay stick with that and hold the kernel packages if you're happy with them.
-
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.
-
Mmmh, I will try to check in the next week if there is something wrong with the driver, please be patient...!
-
I don't have an nvme ssd around to replicate this problem, but still I don't understand what you mean with "github sources". Also your dump is a broken link.
-
I don't know if it has already been fixed, but the last time I tried the RC images, the Terminator font was huge again.
I tested 32 bit Tinkerboard and 64 bit Orange PI 4 LTS jammy xfce images.
-
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?
-
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.
-
I have a better answer: use the forum search tool, or maybe google.
The answer is just around the corner.
-
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.
-
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.
-
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.
-
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.
-
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.
-
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.
CSC Armbian for RK322x TV box boards
in Rockchip CPU Boxes
Posted
@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.