Alex ThreeD Posted September 12 Posted September 12 @Matt H. have you tried to boot X88 from this sd-card? NTFS partition probably will be resized on the first boot. Burning tools just write image file as-is, it is not intelligent enough to resize partitions for different SD sizes 0 Quote
callegar Posted September 23 Posted September 23 A quick msg to kindly ask what should be the current kernels with an RK3318/28 TV Box. My system is currently on -edge and having 6.8.11 installed, but reading here that doing an upgrade on edge, people are receiving 6.10. At the same time `armbian-config` -> System -> Other does not even show me my own kernel among the options, edge being at proposed at 6.7 (associated at armian 24.2.1) and current at 6.6. Is there anything wrong with my config? Is it normal not to see edge kernels associated to the most recent armbian releases (e.g. 24.8.2)? 0 Quote
targa Posted September 27 Posted September 27 (edited) Hi, I'm trying to install a box with above mentioned board. I can boot into multitool, I'm ending up in a root shell then, from which I can start "multitool.sh". It shows me the GNU license, but whatever I do, I usually end up in either ending the tool or starting a backup. So I'm actually blind. I tried screen and minicom on Linux, export TERM=linux on the root shell, and I get some improvements, but mainly in how colorful the output is, I can't see what is supposed to come after the license. Any hint what I need to change in order to see things ? Thanks a lot. [EDIT: nevermind, I was able to perform the steps "blindly" using the screen shots that were part of the linked tutorial at the beginning of this thread. ] Edited September 27 by targa 0 Quote
MattWestB Posted September 28 Posted September 28 (edited) Looks like the kernel problems have being fixed and working as expected updating jammy stable: /_\ _ _ _ __ | |__(_)__ _ _ _ / _ \| '_| ' \| '_ \ / _` | ' \ /_/ \_\_| |_|_|_|_.__/_\__,_|_||_| v24.8.3 for RK3318 Box running Armbian Linux 6.6.47-current-rockchip64 Packages: Ubuntu stable (jammy) Support: DIY (community maintained) IP addresses: (LAN) 192.168.2.X (WAN) X.X.X.X Also possible updating to Noble after getting all updates installed with command do-release-upgrade but is little work getting the external apt-sources working after being done (hint: /etc/apt/sources.list.d/ ). Edited September 28 by MattWestB 0 Quote
Fr id Posted September 28 Posted September 28 13.11.2021 в 21:09, jock сказал: The backup made by multitool (and rkdeveloptool) is per nature a full backup of all the physical eMMC sectors. It has no knowledge of the abstract structures like filesystem and files. The compression gives back a more manageable file which is not the entire size of the eMMC, but up to a few gigabytes, depending on how much data is stored on the eMMC and how much compressible it is. Indeed if you decompress it, you get the whole size of the eMMC, it is expected and it is advisable too. If it is not so, it means the backup process didn't went right. Hey! I'm very new to this topic, do you mind helping? I installed your Multitool on an SD card, got the TV box backup, but now I have a 5 GB backup.gz file, and when I open it, theres a file without extention there. What programs would you advise to use (i'm on Windows 10) to extract the firmware from it and then put it back to this format later? If I understand it correctly, I need to decompress it with some program, edit, then compress it back with something and then flash to the TB box? Maybe there's some noob friendly guide out there that I didn't find, or you can explain the details yourself? My goal is to get the firmware, then edit it - translate to another language, add some games, etc, then flash it back to the TV box. Thank you! 0 Quote
jock Posted September 29 Author Posted September 29 21 hours ago, Fr id said: My goal is to get the firmware, then edit it - translate to another language, add some games, etc, then flash it back to the TV box. Sorry but this is the wrong place to ask about that; no Android or custom setups here, just armbian. 0 Quote
Fr id Posted September 29 Posted September 29 1 час назад, jock сказал: Sorry but this is the wrong place to ask about that; no Android or custom setups here, just armbian. OK so what program to use to decompress the backup file made by Multitool, then edit the armbian firmware and compress it again? 0 Quote
jock Posted October 2 Author Posted October 2 Hello, I am working on an alternative fd6551 and clones led driver for our tv boxes front displays. It is getting up in very good shape, but requires some tuning up; I would like to ask anyone who owns a box with a front led panel and is interested to report the board name, the display chip (common chips are fd6551, fd650, tm1650, etc...) and the original stock dts if possibile. It would make things easier to support already existing boards. Thank you! edit: for source code and reference: https://github.com/paolosabatino/leds-fd6551 2 Quote
Netraam31 Posted October 3 Posted October 3 23 hours ago, jock said: and the original stock dts if possibile. Happy to assist - any instructions on getting the file needed? So far my attempts to mount an android partition in multitool didn't really seem to work well, and I've been using "strings" on the bare partition to get a few text files that I wanted.. 0 Quote
jock Posted October 3 Author Posted October 3 @Netraam31 well, first of all it would be useful to share the board name you got and the led driver chip you have. perhaps I already got the dts and so you don't need to extract it. To extract it, the procedure is totally manual, I use a hex editor for that, so if you have no clue on how to do it never mind. 1 Quote
Netraam31 Posted October 3 Posted October 3 I have an X88 PRO-B-RK3318-D4-V1.6 (2021-09-25) here with led display. (Commercial name X88 Pro 10) Led display chip marking was barely readable but with the lighting in a specific angle I was able to read: AiP1628. Which does not appear to be pin compatible with the fd6551, but looks like it could be fd628 compatible. Not sure how far off those two are - didn't look into datasheets yet. So could very well be out of scope for your driver. Happy to upload original "chinese" firmware/find relevant files/... if that would help. Also have an RK3318_V1.4 202303.200629 that appears to have a compatible PCB for fd6551 chip but this doesn't have the chip populated (and no leds other than blue and red smd leds on the pcb). 0 Quote
hexdump Posted October 3 Posted October 3 @jock - are you aware of https://github.com/jefflessard/tm16xx-display/ via ? 0 Quote
jock Posted October 3 Author Posted October 3 @hexdump Ah, no I wasn't! It looks like I reinvented the wheel 😅 And that kernel driver is written very well with broader support too. 0 Quote
jock Posted October 3 Author Posted October 3 @Netraam31 thanks for checking ,but actually no, your chip is not compatibile. Anyway my driver is just born and dead too, tm16xx is a much better alternative (and supports your chip too) I will integrate it into armbian sooner or later. 0 Quote
MattWestB Posted October 6 Posted October 6 I have 2 H69Max branded boxes with 4G RAM and 64G eMMC. PCB is only labeled RK3318_V1.4 with fd6551 LED-driver chip. Using LED conf 7 and working great WiFi and BT AP6330 looks working OK but using Eth for network access. Only USB is worse then other RK3X boxes if using little bandwidth on them. I have one backup of original Android but its very large and must look if i can extracting the original DTS files from it. 0 Quote
jock Posted October 7 Author Posted October 7 @MattWestB led-conf7 does not exist on rk3318 build, it is just up to led-conf5 I introduced very recently; your board should fit into the base device tree. Anyway, if you'd like to test the new tm16xx driver (which include support for fd6551 and several other led driver chips) you'd need to switch to the armbian beta repository, but beware of the dragons ahead! So take a full backup first! You can switch to beta repository in armbian-config or by changing apt.armbian.com to beta.armbian.com in /etc/apt/sources.list.d/armbian.list Then run apt update and upgrade at least the kernel, dtb and armbian-bsp-cli-rk3318 packages, then reboot, run rk3318-config and (for your specific case) you should be able to test the fd6551 driver with led-conf5 (YX_RK3318 board) Now that you are confirming me that RK3318_V1.4 also have a display panel and the fd6551, I can update your board device tree too. Notice that it should be handy to know if leds and segmentes are displaying correctly. You can make reference to the original driver https://github.com/jefflessard/tm16xx-display on how to configure and tweak the driver for your specific board. Everything which is there applies as-is. The same applies for other people with X88 and YX_RK3318 boards: there the led-conf that applies to their board should be already working out-of-the box! 1 Quote
mkultra Posted October 8 Posted October 8 hi, had to reflash one of my boxes.... did an update so on latest v24.11 rolling but I get an error in armbian-config when I go to set a static ip "/usr/lib/armbian-config/functions-network.sh: line 229: route: command not found" and I'm missing /etc/network/interfaces.........just an interfaces.out file that is 'not a file' apparently lol how do I change to a static IP? cheers 0 Quote
MattWestB Posted October 8 Posted October 8 (edited) Thanks @jock and the LED cofig was from memory and form the very old install and it was running on the default one. Something is crashing the kernel then loading modules but i shall looking if its being OK then not loading the new drive. And in the e log: [Tue Oct 8 20:04:53 2024] tm16xx_led_set+0x60/0x6c [tm16xx] [Tue Oct 8 20:04:53 2024] tm16xx_probe+0x390/0x6e0 [tm16xx] [Tue Oct 8 20:04:53 2024] tm16xx_i2c_probe+0x5c/0x80 [tm16xx] [Tue Oct 8 20:04:53 2024] tm16xx_init+0x5c/0x1000 [tm16xx] [Tue Oct 8 20:04:53 2024] tm16xx 4-0024: Display initialized successfully So its loaded OK. But cant testing it by instruction then the display-utils is not installed and i cant finding how to do that. The service call is also not working (/sbin/display-service dont exist) but writing to sys-class is working OK. cat /sys/class/leds/display/digits 4 3 2 1 cat /sys/class/leds/display/segments 0 1 2 3 4 5 6 echo "boot" > /sys/class/leds/display/value Is showing "BOOT". Do you have some other ways testing the e display and setting up service call ? Thanks for great work done and continuing doing it well !!! Edit: Was looking in the Makefile and was doing the "install: module module-install service-install" part manually and now its working !!! I think we need one package for installing it in the system for normal users and adding boot and WiFi / Eth indicator from OS. Edited October 8 by MattWestB 0 Quote
MattWestB Posted October 8 Posted October 8 @mkultra Looks like the command package is not installer as standard in ubuntu: # route Command 'route' not found, but can be installed with: apt install net-tools But install net-tools it shall working OK (I hope) 0 Quote
jock Posted October 8 Author Posted October 8 @MattWestB I decided not to provide the service scripts yet because they provide different functionality and can be installed or altered manually by any user. Also not all the boards have the front display. The driver, clearly, is a different beast and is easier to be shipped within the kernel package. As you can see, the services can be downloaded from the github repository and installed manually or, if you like, you can package them into a .deb and I will be happy to host it on users.armbian.com By the way, the driver requires a device tree node, you can't just modprobe it into and expect it works. You have to select the right device tree overlay with rk3318-config and some leds (LAN, for example) will be autoconfigured as well. About the "command package", route is deprecated, you should use ip route instead thanks for reporting the digits order and segments order; individual leds can be accessed within /sys/class/leds as well 0 Quote
MattWestB Posted October 9 Posted October 9 Have testing more and all display elements is working OK. But the kernel is having problem then loading the module: [Wed Oct 9 09:18:18 2024] ------------[ cut here ]------------ [Wed Oct 9 09:18:18 2024] WARNING: CPU: 0 PID: 442 at kernel/workqueue.c:1788 __queue_work+0x480/0x578 [Wed Oct 9 09:18:18 2024] Modules linked in: ch341(+) brcmutil v4l2_vp9 videobuf2_dma_contig tm16xx(+) v4l2_h264 usbserial cfg80211 ledtrig_netdev snd_soc_spdif_tx videobuf2_dma_sg hci_uart v4l2_mem2mem btqca videobuf2_memops btrtl btintel gpio_ir_recv dw_hdmi_i2s_audio videobuf2_v4l2 rc_core videodev btbcm bluetooth lima dw_hdmi_cec snd_soc_rockchip_spdif videobuf2_common snd_soc_rk3328 snd_soc_rockchip_i2s rfkill snd_soc_simple_card snd_soc_simple_card_utils gpu_sched mc drm_shmem_helper rk_crypto snd_soc_core rng_core snd_compress snd_pcm_dmaengine snd_pcm snd_timer snd soundcore cpufreq_dt zram binfmt_misc sch_fq_codel dm_mod nfnetlink ip_tables x_tables autofs4 dwmac_rk stmmac_platform stmmac pcs_xpcs gpio_syscon adc_keys [Wed Oct 9 09:18:18 2024] CPU: 0 PID: 442 Comm: (udev-worker) Not tainted 6.6.54-current-rockchip64 #1 [Wed Oct 9 09:18:18 2024] Hardware name: Rockchip RK3318 BOX (DT) [Wed Oct 9 09:18:18 2024] pstate: a00000c5 (NzCv daIF -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [Wed Oct 9 09:18:18 2024] pc : __queue_work+0x480/0x578 [Wed Oct 9 09:18:18 2024] lr : __queue_work+0x1e4/0x578 [Wed Oct 9 09:18:18 2024] sp : ffff80008166b540 [Wed Oct 9 09:18:18 2024] x29: ffff80008166b540 x28: ffff199e48f132b0 x27: 0000000000000000 [Wed Oct 9 09:18:18 2024] x26: ffffbc7084518008 x25: ffff199e4041e000 x24: ffffbc708487dcb8 [Wed Oct 9 09:18:18 2024] x23: ffff199e48f132b8 x22: 0000000000000011 x21: ffff199e40408400 [Wed Oct 9 09:18:18 2024] x20: 0000000000000100 x19: ffff199f3e72ee40 x18: ffff199f3e7af04c [Wed Oct 9 09:18:18 2024] x17: ffff5d2eba203000 x16: ffff800080000000 x15: 00000000000001ef [Wed Oct 9 09:18:18 2024] x14: 0000000000000000 x13: ffffbc70841cc198 x12: ffffbc7084879b68 [Wed Oct 9 09:18:18 2024] x11: 0000000000000040 x10: ffffbc7084897470 x9 : ffffbc7084897468 [Wed Oct 9 09:18:18 2024] x8 : ffff199e40800028 x7 : 0000000000000000 x6 : 0000000000000000 [Wed Oct 9 09:18:18 2024] x5 : ffff199e40800000 x4 : 0000000000000000 x3 : 0000000000000001 [Wed Oct 9 09:18:18 2024] x2 : 0000000000000000 x1 : 0000000000000000 x0 : 0000000000000000 [Wed Oct 9 09:18:18 2024] Call trace: [Wed Oct 9 09:18:18 2024] __queue_work+0x480/0x578 [Wed Oct 9 09:18:18 2024] queue_work_on+0x68/0x84 [Wed Oct 9 09:18:18 2024] tm16xx_led_set+0x60/0x6c [tm16xx] [Wed Oct 9 09:18:18 2024] led_set_brightness+0x90/0xe0 [Wed Oct 9 09:18:18 2024] led_trigger_set+0x268/0x274 [Wed Oct 9 09:18:18 2024] led_trigger_set_default+0xa4/0xcc [Wed Oct 9 09:18:18 2024] led_classdev_register_ext+0x284/0x3a0 [Wed Oct 9 09:18:18 2024] devm_led_classdev_register_ext+0x58/0xb0 [Wed Oct 9 09:18:18 2024] tm16xx_probe+0x390/0x6e0 [tm16xx] [Wed Oct 9 09:18:18 2024] tm16xx_i2c_probe+0x5c/0x80 [tm16xx] [Wed Oct 9 09:18:18 2024] i2c_device_probe+0x104/0x2e8 [Wed Oct 9 09:18:18 2024] really_probe+0x184/0x3c8 [Wed Oct 9 09:18:18 2024] __driver_probe_device+0x7c/0x16c [Wed Oct 9 09:18:18 2024] driver_probe_device+0x3c/0x110 [Wed Oct 9 09:18:18 2024] __driver_attach+0xf4/0x1fc [Wed Oct 9 09:18:18 2024] bus_for_each_dev+0x74/0xd4 [Wed Oct 9 09:18:18 2024] driver_attach+0x24/0x30 [Wed Oct 9 09:18:18 2024] bus_add_driver+0x110/0x234 [Wed Oct 9 09:18:18 2024] driver_register+0x60/0x128 [Wed Oct 9 09:18:18 2024] i2c_register_driver+0x48/0xec [Wed Oct 9 09:18:18 2024] tm16xx_init+0x5c/0x1000 [tm16xx] [Wed Oct 9 09:18:18 2024] do_one_initcall+0x44/0x2c4 [Wed Oct 9 09:18:18 2024] do_init_module+0x58/0x1e8 [Wed Oct 9 09:18:18 2024] load_module+0x1c94/0x1ec4 [Wed Oct 9 09:18:18 2024] init_module_from_file+0x84/0xc4 [Wed Oct 9 09:18:18 2024] __arm64_sys_finit_module+0x1f4/0x2f0 [Wed Oct 9 09:18:18 2024] invoke_syscall+0x48/0x118 [Wed Oct 9 09:18:18 2024] el0_svc_common.constprop.0+0xc8/0xe8 [Wed Oct 9 09:18:18 2024] do_el0_svc+0x20/0x2c [Wed Oct 9 09:18:18 2024] el0_svc+0x40/0xf4 [Wed Oct 9 09:18:18 2024] el0t_64_sync_handler+0x13c/0x158 [Wed Oct 9 09:18:18 2024] el0t_64_sync+0x190/0x194 [Wed Oct 9 09:18:18 2024] ---[ end trace 0000000000000000 ]--- And the service is not loading OK then the "ExecStart=/usr/sbin/display-service" is pointing to "/sbin/display-service". Fixing it but the service cant starting then its missing some files that very likely is handles from the module that is not working OK. Good thing is that pause is used and activity LED and WiFi and Eth looks working OK also USB activity is working (Zigbee stick). If getting the service working then it shall showing the time on the display if not configure somthing else. Some hints getting the module loading OK and getting the service working OK ? 0 Quote
MattWestB Posted October 9 Posted October 9 Was getting the service working but i cant saying way it was not working but some problems with the files the system cant accessing. Kernel still have some problem then loading the module but looks working as aspected. The time its ticking !!!! 0 Quote
jock Posted October 9 Author Posted October 9 About the service and driver issues, you could post in the post of the author about the kernel module: I'm glad you tested also the indivual leds and they work; I will integrate those into the RK3318_V1.4 device tree overlay 1 Quote
MattWestB Posted October 10 Posted October 10 Was installing the original Android backup and installing SSH server on it and then one "tar -zcvf device.tar.gz /sys/firmware/devicetree/base/" for dumping the device tree and attaching it her if you need it but i think its the same as your box.device.tar.gz 0 Quote
Alex ThreeD Posted October 12 Posted October 12 (edited) @jock What do you think about plug-and-play Armbian image that can boot from SD on stock STB without original firmware wipe from eMMC, just like multitool? From your previous messages in this thread it looks you have concerns with rk blob bootloader security, and want to wipe original bootloader ASAP I’ve made some experiments and managed to make SD layout with dual u-boot: first u-boot is the same as it is now (with upstream opensource ATF, etc), second u-boot is blob-only that is used only to boot on STB with stock bootloader on eMMC. Will you accept such a PR? Edited October 12 by Alex ThreeD 0 Quote
jock Posted October 12 Author Posted October 12 4 hours ago, Alex ThreeD said: I’ve made some experiments and managed to make SD layout with dual u-boot: first u-boot is the same as it is now (with upstream opensource ATF, etc), second u-boot is blob-only that is used only to boot on STB with stock bootloader on eMMC. Will you accept such a PR? Actually the main trigger for bootloading is the miniloader, which leads to boot from sdcard or emmc depending on what it finds in sdcard. If there is a proper signature in some expected addresses, it will load u-boot and trust OS from sdcard, otherwise goes with emmc. Also it will check for GPT partition table searching for the address hints where to find uboot and trust os. Actually you should not need to supply a trust os: uboot (called the "loader) should suffice for the rockchip miniloader. Anyway, the main idea is to wipe all the proprietary blobs and keep the bare minimum to do the job. Currently, despite u-boot is capable of initializing DDRs on rk3328, the rockchip ddrbin is kept proprietary for broader DDR compatibility among the boards, the rest is fully open source. The proprietary trust OS would also allow DDR frequency scaling, but it is doing nasty things and crashes the SoC when you run it faster than 1.1GHz. Dual boot may be interesting, but at the moment I won't merge that unless there are very important advantages. 0 Quote
Alex ThreeD Posted October 12 Posted October 12 (edited) 1 час назад, jock сказал: Actually the main trigger for bootloading is the miniloader, which leads to boot from sdcard or emmc depending on what it finds in sdcard. Maybe I'm not right, but I think emmc here has a priority over sdcard. AFAIC hardware BootROM first tries to load TPL/SPL from emmc and then if it is failed BootROM tries to load TPL/SPL from sdcard. Proprietary SPL found on stock emmc first tries to load trustos/uboot-proper from sdcard and then from emmc (the opposite priorities here). The good news is that proprietary SPL doesn't use fixed sdcard locations, but tries a few locations in range 8-16 MB at the start of sdcard (backups in case of broken flash memory?). So we could use (currently unused) area near the end of first 16MB block to place additional trust/uboot in a format suitable for proprietary SPL - it won't be used during "normal" boot after emmc wipe, but it would allow to check Armbian loaded from sdcard in "live" mode before wipe. Ok, I understand your concerns with proprietary blobs, wont push it further. Edited October 12 by Alex ThreeD 0 Quote
jock Posted October 12 Author Posted October 12 @Alex ThreeD yes, the proprietary SPL (the "miniloader") bahaves that way: I'm going by memory so I may be faulty about numbers, but in general it starts from an address (sector 0x2000) and tries to find the LOADER signature; if it does not find the signature, retries adding 0x800 sectors and so it goes on... Then does the same for the trust os (looks for TOS), starting from sector 0x4000. As said, numbers may not be exact. What is not really widely known is that you can put a GPT partition table on the flash and name the partitions uboot (or u-boot, can't remember exactly) and trustos and the miniloader will start looking directly there. About the bootrom and miniload order, you're right: bootrom first tries from emmc, then from sdcard. miniloader first checks the sdcard, then emmc. This is a great source of pain when dealing with booting on rockchip; allwinner, for example, has the bootrom that boots first from sdcard and then emmc and everything is much simpler there. 0 Quote
Vidhome Posted October 15 Posted October 15 Jock thank you for your work! Everything worked on my H96Max RK3318. The sequence was as follows: 1. switch to beta repository in armbian-config or by changing apt.armbian.com to beta.armbian.com in /etc/apt/sources.list.d/armbian.list 2. run apt update and upgrade at least the kernel, dtb and armbian-bsp-cli-rk3318 packages, then reboot, run armbian-config (Software->Hardware->and on led-conf5) 3. apt install git make linux-headers-edge-rockchip64 -y 4. git clone https://github.com/jefflessard/tm16xx-display.git; cd tm16xx-display; ln -s /boot/System.map-`uname -r` /lib/modules/`uname -r`/build/System.map 5. make install The clock is ticking, the indicators are working. After the Homeassistant docker. 1 Quote
jock Posted October 15 Author Posted October 15 @Vidhome I'm glad it worked, but you didn't really need to compile the driver yourself, it should have worked out of the box after choosing led-conf5 and rebooted 0 Quote
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.