jock
-
Posts
1860 -
Joined
-
Last visited
Content Type
Forums
Store
Crowdfunding
Applications
Events
Raffles
Community Map
Posts posted by jock
-
-
@pakos96 That's right, the flashing leds are made on purpose to have a visual feedback that the kernel is alive.
Once you setup the led-config suitable for your board, you can change the led behaviour writing to /sys/class/leds/working/trigger. You can even read that file to know which are the available triggers.
-
@Slash402 actually, I don't even know if there is real fault in the hardware or 4 chips are fake or whatever... looking at the PCB there are 8 chips of 2 gigabits each, so they should account for a total of 16 gigabits = 2 gigabytes.
Now 1 gigabyte is missing, but who knows why... the tricks and gimmicks of chinese cheap tv boxes are infinite.
The original idbloader runs the memories at 666 mhz, it is a very nice bump in general performance against the 333 mhz of these other idbloaders, so I suggest to use the original one if it works ok for you.
-
@MattWestB beware that rk3318-config does not let choose DDR frequency, that's for rk322x.
rk3318 requires proprietary trust os to enable the ddr scaling, but the proprietary os does not allow frequencies above 1.1ghz artificially crashing the system.
For this reason, on rk3318 I'm using the mainline opensource trust os, which allows to run the cpu above 1.1ghz without issues, but does not support ddr scaling.
That's it, closed source code 🙄
-
@Slash402 thanks for testing, as I suspected the issue is not in the software but in the hardware. This clarifies some other dubious cases that were raises in the rk3318 thread where other people was claiming similar issues.
Sorry, but I think there is really nothing to do about 🤷♂️
Perhaps you could put the board in the oven, if there is a soldering issue... I'm not joking, it is a known trick to do cheap "reflowing" of the BGA chip soldering. Of course it can melt down the whole board...
-
8 hours ago, otus said:
How to check ram speed in armbian and why video on youtube plays very poorly?
You can check the dpll core clock in linux, it tells you the clock used by the dram controller.
cat /sys/kernel/debug/clk/dpll/clk_rate
It should tell you 666Mhz or 1333Mhz, I don't remember if it accounts for double-data rate or not (but I think not, probably will tell 666Mhz).
edit: about the poor youtube performance, it is due to the fact that the cpu is not powerful enough, there is no hardware video decoding yet for videos in the browser and the graphics pipeline is not really well optimized for general purpose desktop environments.
-
Tested Asus Tinkerboard:
- Armbian_23.02.1_Tinkerboard_jammy_current_6.1.11_xfce_desktop.img.xz
Most of the hardware seems to work pretty fine and the board is stable.
Bluetooth adapter is not detected at all (perhaps some kernel config bits are missing? Need to check this...).
I got a weird stack trace when launching the "Celluloid" application, but it seems more a kernel bug rather than anything related to armbian.
An old 2Gb USB stick did trigger lot of weird USB errors, the stick works perfectly elsewhere, perhaps some compatibility issues. Overall, USB ports are working with other devices.
Wireless performance is swinging from 1 mbps to 12 mbps, not really clear why, but connection is stable.
-
Tested OrangePi 4 LTS:
- Armbian_23.02.1_Orangepi4-lts_jammy_current_5.15.93_xfce_desktop.img.xz
- Armbian_23.02.1_Orangepi4-lts_bullseye_current_5.15.93_minimal.img.xz
Bluetooth adapter is detected, but this time I was unable to pair with the usual audio speaker
The rest seems to work pretty well
-
@Slash402 Okay, so here it is.
I attach two "alternative" idbloaders, you can try both of them to see if something changes.
I strongly suggest you to do these tests on a sdcard rather than emmc. If something goes bad on the sdcard, swapping it is easy. If something goes bad on emmc, you will soft-brick the board and need to force it in maskrom mode (it is not pleasant task to do).
If you want to go the sdcard way, you will need to first erase the eMMC completely using the multitool, then just burn armbian on sdcard and boot the tvbox with the sdcard inserted.
The devices are:
- sdcard = /dev/mmcblk0
- emmc = /dev/mmcblk2
To backup the existing idbloader:
dd if=/dev/mmcblkX of=idbloader.old bs=32k skip=1 count=4
(change mmcblkX with the device you choose, so mmcblk0 if you choose the sdcard way, mmcblk2 if emmc)
To burn a new idbloader:
dd if=idbloader-333mhz-1.16.img of=/dev/mmcblkX bs=32k seek=1 conv=fdatasync
(again, change mmcblkX accordingly as above).
then reboot and see if something changes.
You can also try idbloader-333mhz-alt.img idbloader using the same command.
-
6 hours ago, Slash402 said:
As for the flash? Is it just 16GB or more?
I'm afraid there are no chances for more, if the kernel detects such amount, that's it.
The one and only doubt I have is the "modded" 666mhz ddrbin in place of the "standard" 333mhz ddrbin could have some role in this.
If you want I can give you a 333mhz bootloader and the instructions to quickly install it for a definitive test.
-
-
@Slash402 Mmh, if you didn't cut the firmware on purpose, then it may be that the eMMC is broken, it has been reported in the past that these boards have very lousy soldering and the eMMC is often failing after a while, just be aware of this.
About the soldering points, this is the front side of my board:
You can see I soldered an array of holes in the bottom-left corner. You can solder directly some wires to the pads or do whatever you find better for your case. The pin with the downward arrow is Ground (GND) and this must be absolutely connected to GND of the serial adapter. The two immediate pins on the left of the GND pin are TX and RX. Honestly I don't remember which one is RX and TX, so you have to connect them to RX and TX pins of the serial adapter and see if it works; if it does not work, switch the pins. The leftmost pin should be left unused.
About the software to use, I don't know if you use linux or windows. For Windows Putty is surely one of the best options, on Linux there is a pletora of suitable application like minicom or picocom. You can search with google. Transmission parameters are: 1500000 bps (1.5mbps), 8 bits per symbol, no parity, 1 stop bit ("8N1" for friends).
Good luck!
-
-
@Slash402 Thanks for the firmware, it looks like there is only the first part of the firmware and not the whole eMMC image. It is sufficient to do some tests on my board, but beware that you won't be able to restore the original system with that, I hope you cut the file on purpose...
About the serial adapter, yes it is the one you shown in the photo. On the "front" side of the board you have the serial pads (there are "GND", "RX" and "TX" label markings nearby) that you solder and connect to the serial adapter to grab the serial output of the box. The baud rate of the serial must be set to 1.5mbps
-
-
@Slash402 Well actually *i suppose* you have 8 chips (the other 4 should be on the other side). To be sure I need both the serial output of the box when it boots and the original firmware of your board. There are several reports that armbian detects a lower amount of memory than installed chips, but we have not yet understood if the chips are fake or the issue is really software-related.
-
-
6 hours ago, nome cognome said:
@jock : how come multitool will boot from an sd card no matter what while the armbian image needs the flash to be erased first?
That's a deliberate choice to avoid proprietary rockchip binaries as most as possible or use "tested" binaries, use mainline u-boot and keep the bootloader part "tiny".
In reality, these assumptions were made initially for rk322x images, where the bootloader has been compacted into the first 2 megabytes of emmc, but on the rk3318 images this is partially true.
To make the long story short, the multitool uses the rockchip proprietary boot layout, while on armbian there is a custom layout and custom binaries.
Since rockchip socs always boot from eMMC first, the stock bootloader is fired first and it does not like custom layouts. To run armbian from sdcard you need to remove the stock bootloader, thus the fastest way is to erase the eMMC.
-
7 hours ago, RaptorSDS said:
last time i install desktop without preinstall ( Dietpi and xfce ) all text and all symbol where missing . Thats was not a good experiance .
Yup, often you need some other "recommended" packages to get the whole thing working right. Sometimes they are listed as reccomended/suggested packages by apt itself, some other time they even are not
That's the same for weston, for example: if you install the "weston" package it just does not work if there aren't the EGL/OpenGL libraries already installed.
-
@regepower Hello, don't expect great desktop performance, the SoC is generally very limited and it was not its purpose to run x11 desktop. The best thing you can do, if you already didn't, is to disable the desktop compositor from setting -> windows manager tweaks -> compositor. Generally this helps a bit with performance, but as said, it won't change a mouse into a kangaroo 🙃
-
@Dario Murgia Don't worry, it is not essential, it was just good to know. However the fix has been mainlined in armbian
-
@Dario Murgia ok thanks also for this other clarification and yes, that's exactly the way you describe: so, only the X88 Pro overlay will receive this fix 👍
edit: do you remember the other board signature on the pcb?
-
@Dario Murgia Very, cool thanks for reporting! In fact I had no chance to test SPDIF when I originally worked on rk3318-box dts because my old board had no spdif. I will check on the newer board if the spdif is working selecting the other pin configuration and put a general fix for the dts!
-
@Dario Murgia Mmmh, I had the chance to try an image with latest 6.1 kernel on a rk3328 box and audio was not properly working in any case.
Analog audio is working with speaker-test/aplay but not with pulseaudio on xfce, SPDIF was completely not working. Pulseaudio also was missing one of the three audio devices.
Definitely I need to take a look to this, I recently received a rk3328 board with SPDIF coaxial connector and thus I can try, but you have to be patient. The nodes in the device tree seems to be in place, but perhaps some setting is wrong or a gpio that enables/disables the spdif output is missing. I need to check that.
-
2 hours ago, tommyboy said:
Hi Joke, i tried with new multitool but result is same no success.
Maybe there is something wrong with the tv box, thanks for the help.
Well, I don't know exactly, but I don't think your board has a problem. Most probably the issue is in the closed binary code that does something that put the board in suspend. Usually this does not happen with other boards, just with yours and I have no explanation for that.
A possible solution would be to use an opensource trust os, which is available for rk322x, but it is something I can't do in a matter of few days but requires some further study to integrate it into the rockchip boot flow successfully.
HK1 Max RK3318 4/64 Reporting different/wrong RAM/ROM size
in Rockchip CPU Boxes
Posted
Yes I made some precompiled images in the past, but they are not updated anymore because there are the "nightly" ones.
I suggest you to go with nightlies, which are updated very often, even though they are not declared "stable" because they come with the "edge" kernel flavour. You can always switch to a "current" (ie: older kernel, considered "stable") kernel using armbian-config if you prefer. The only drawback with nightlies is that the userland comes with debian sid or latest ubuntu, which is not always an optimal choice (debian sid is way too edgy, for my tastes).
Yes I am