TonyMac32 Posted January 28, 2018 Posted January 28, 2018 Hello everyone, I've begun working to target the Armbian Legacy Tinker Board build to the Rockchip kernel. There are a list of reasons why it needs done, including some relatively large differences between the current kernel's code base and the Rockchip kernel (making it hard to patch with bugfixes/etc) and inactivity on the part of the vendor of that kernel. There are also reasons I am preferring to use the Rockchip kernel rather than the ASUS kernel. First and formost is the need to also support the MiQi. The miniarm branch of Rockchip and the ASUS kernel have board-specific fixes written in such a way as to not be friendly to other boards. I've decided it would in fact be easier and more reliable to use the Rockchip kernel and apply the needed fixes in the most appropriate way for our project, as we have different needs than a board-specific vendor kernel. This is a build-it-yourself situation. This is a fork of the Armbian build system using the Rockchip kernel source from https://github.com/rockchip-linux/kernel Things that work and are tested: Wireless Bluetooth (via the typical hci attach method) 4k/2k/1080 Raspberry Pi touchscreen Compiles with gcc 7.2.1 [resolved] Mali is somehow only building for Android, "Mali for linux" throws error during build. This has been clarified, I reached out to Rockchip, this kernel config is simply to allow using older drivers with Linux if so desired. I don't see immediate reason to desire, so good. [resolved] HDMI Blanking out on change from 4K to other resolutions. Somehow switch to 4k is ok. Rockchip adjustments to drivers fixed this for my use case, waiting to hear other feedback VPU/Mali tested/a tutorial by @JMCC Things not worked out: RGA/VPU/etc are untested/unconfigured/incomplete. Not tested 100%, but working (RGA uncertain) Other things I'm sure. What is needed are people able to test the kernel and determine if it is able to be rolled out. The kernel presently used is no longer maintained by the vendor, and split from Rockchip too long ago to be able to patch it appropriately. 1
Tido Posted January 29, 2018 Posted January 29, 2018 16 hours ago, TonyMac32 said: and inactivity on the part of the vendor of that kernel. it is a bit difficult to understand what you mean, without giving a name to the Kernels e.g. armbian-Kernel, Rockchip-Kernel, ASUS-Kernel? Maybe you can edit your post in that regard ? 16 hours ago, TonyMac32 said: *** HDMI currently blanks out on resolution change. Well, how often do you change resolution/display while running it. I attach it to a display and if I move it to another display.. in another room I usually have to shutdown/boot anyway.
TonyMac32 Posted January 29, 2018 Author Posted January 29, 2018 23 minutes ago, Tido said: it is a bit difficult to understand what you mean, without giving a name to the Kernels e.g. armbian-Kernel, Rockchip-Kernel, ASUS-Kernel? 16 hours ago, TonyMac32 said: The kernel presently used is no longer maintained by the vendor, and split from Rockchip too long ago to be able to patch it appropriately. https://github.com/armbian/build/blob/2c049615d55a1e7f88fe58e2061c299f5a4ac3b6/config/sources/rockchip.conf#L19 ------ 26 minutes ago, Tido said: Well, how often do you change resolution/display while running it. I attach it to a display and if I move it to another display.. in another room I usually have to shutdown/boot anyway. I mostly agree, but it is a regression from current capability.
Tido Posted January 30, 2018 Posted January 30, 2018 On 28.1.2018 at 7:25 PM, TonyMac32 said: What is needed are people able to test the kernel and determine if it is able to be rolled out. Basically, people with a tinker board and like to setup a build environment - as described in the Readme - shall run the compiler, burn it, run it and come back with their findings. It should even work with Mali ?
TonyMac32 Posted January 30, 2018 Author Posted January 30, 2018 1 minute ago, Tido said: should even work with Mali ? It should. It should also be theoretically possible to use the mpp platofrm for video decoding as well, something I haven't yet tested, along with device tree overlays (see most recent commit). I haven't made an image because I don't want an explosion on my hands, but a show of hands who can test that wouldn't be able to build it?
TonyMac32 Posted January 31, 2018 Author Posted January 31, 2018 OK, in a last attempt, ***use at your own risk***, and only for evaluation purposes. debian packages for kernel/bootloader/etc I also noticed the one up now is claiming to be "4.4.112", but there is a failed incremental patch after I merged the current build system to get mine up to date. root@tinkerboard:~# lsmod Module Size Used by uas 20480 0 zram 28672 4 lz4_decompress 16384 1 zram lz4_compress 16384 1 zram 8723bs 1253376 0 On resolution change from 4k this kernel still gets DRM crash resulting in oops, going to do some debugging, if anyone else has seen this let me know. Spoiler [ 1386.115332] rockchip-vop ff930000.vop: [drm:vop_crtc_enable] Update mode to 3840*2160, close all win [ 1386.167778] [drm:hdmi_config_hdr_infoframe] *ERROR* Not support DRM Infoframe [ 1427.353264] Unable to handle kernel NULL pointer dereference at virtual address 00000000 [ 1427.362268] pgd = ec744000 [ 1427.365259] [00000000] *pgd=00000000 [ 1427.369216] Internal error: Oops: 5 [#1] SMP ARM [ 1427.374318] Modules linked in: zram lz4_decompress lz4_compress 8723bs [ 1427.381568] CPU: 3 PID: 759 Comm: Xorg Not tainted 4.4.112-rockchip #34 [ 1427.388878] Hardware name: Rockchip (Device Tree) [ 1427.394077] task: ec5bf000 task.stack: ecf86000 [ 1427.399094] PC is at vop_crtc_bandwidth+0x268/0x34c [ 1427.404487] LR is at vop_crtc_bandwidth+0x1ac/0x34c [ 1427.409880] pc : [<c06a14d8>] lr : [<c06a141c>] psr: 60000013 sp : ecf87cd0 ip : ffffff18 fp : ecf87d2c [ 1427.422570] r10: 0000000b r9 : dcf10900 r8 : 00000002 [ 1427.428344] r7 : dcf10440 r6 : ffffff7c r5 : ffffff7c r4 : ffffff18 [ 1427.435558] r3 : 00000000 r2 : 00000004 r1 : ffffff7c r0 : 00000000 [ 1427.442774] Flags: nZCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment none [ 1427.450662] Control: 10c5387d Table: 2c74406a DAC: 00000051
TonyMac32 Posted February 1, 2018 Author Posted February 1, 2018 MiQi tested and booting, however eMMC not showing up, checking config
mpmc Posted February 2, 2018 Posted February 2, 2018 Just thought I'd chime in here and say mine has been running fine headless on next/mainline - log http://ix.io/F6V. But why anyone would want to use (channeling my inner tkaiser here) crusty 4.4 is beyond me, well.. unless the feature is missing from mainline. I'm more than happy to try 4.4 though if it would help!
TonyMac32 Posted February 2, 2018 Author Posted February 2, 2018 1 hour ago, mpmc said: crusty 4.4 is beyond me, well.. unless the feature is missing from mainline. Well, that's exactly the reason. ;-). The video codec/etc are not yet implemented in mainline.
mpmc Posted February 2, 2018 Posted February 2, 2018 5 hours ago, TonyMac32 said: Well, that's exactly the reason. ;-). The video codec/etc are not yet implemented in mainline. I've just installed your debs on stretch, ran into a minor hiccup, but otherwise it seems to run fine - log http://ix.io/F88 Spoiler Selecting previously unselected package linux-u-boot-tinkerboard-default. dpkg: regarding .../linux-u-boot-tinkerboard_5.40_armhf.deb containing linux-u-boot-tinkerboard-default: linux-u-boot-tinkerboard-next conflicts with armbian-u-boot linux-u-boot-tinkerboard-default provides armbian-u-boot and is to be installed. dpkg: error processing archive ./linux-u-boot-tinkerboard_5.40_armhf.deb (--install): conflicting packages - not installing linux-u-boot-tinkerboard-default Setting up linux-dtb-rockchip (5.40) ... Setting up linux-headers-rockchip (5.40) ... Compiling headers - please wait ... Setting up linux-image-rockchip (5.40) ... update-initramfs: Generating /boot/initrd.img-4.4.112-rockchip update-initramfs: Converting to u-boot format Errors were encountered while processing: ./linux-u-boot-tinkerboard_5.40_armhf.deb fix: remove linux-u-boot-tinkerboard-next & install linux-u-boot-tinkerboard HTH 1
bedalus Posted February 2, 2018 Posted February 2, 2018 I'm happy to do some testing. What's the ideal set-up? Download the legacy version and then dpkg the debs? After that, what are we testing for, working features and uptime without random reboots?
TonyMac32 Posted February 2, 2018 Author Posted February 2, 2018 9 minutes ago, bedalus said: Download the legacy version and then dpkg the debs? That would be ideal. Yes, working features is primary, I've had mine running for 5 days on my desk with the wifi/touchscreen, just looking through files/using IRC/etc. Thanks!
bedalus Posted February 3, 2018 Posted February 3, 2018 I've hit a snag. With the default download (Armbian_5.38_Tinkerboard_Ubuntu_xenial_default_4.4.112_desktop) I get nothing on the screen. I also tried a different image for good measure (Armbian_5.37_Tinkerboard_Debian_jessie_default_4.4.104). I think maybe the issue is that it's a 4K TV. I didn't have any issues with my old HD TV, but we got rid of it! Any config changes I can apply after flashing the image so I get an output?
stefan.steffens Posted February 3, 2018 Posted February 3, 2018 I'd like to test too but can someone please tell me which option I'm supposed to pick: -> I select full OS build for flashing (as I don't know how to use the other option) -> don't change the kernel option -> select tinkerboard ?? Then I can chose between - Default (vendor provided / legacy) which I assume is not the correct option - Mainline (@kernel.org) - development version (which I assume to be the correct option) Can someone please confirm that the correct options so that I can test the new kernel?
TonyMac32 Posted February 3, 2018 Author Posted February 3, 2018 Actually "default" is the correct option. Thanks for testing!
Tido Posted February 3, 2018 Posted February 3, 2018 (edited) Tests with original Armbian_5.38_Tinkerboard_Ubuntu_xenial_default_4.4.112_desktop.img root@tinkerboard:~# uname -a Linux tinkerboard 4.4.112-rockchip #7 SMP Thu Jan 25 01:04:58 CET 2018 armv7l armv7l armv7l GNU/Linux root@tinkerboard:~# lsmod Module Size Used by zram 28672 4 lz4_decompress 16384 1 zram lz4_compress 16384 1 zram 8723bs 1232896 0 WiFi = it works I guess RPi-Monitor is removed from armbian-config HDMI-to-DVI 1280x1024 (SXGA) = it works Unplug HDMI and plug in again (same Display) = startx was necessary, but it works Touch screen 1024x600 = it works full screen (touch I did not test) In the on-screen-display the display writes: 1080p Spoiler root@tinkerboard:~# xrandr --verbose Can't open display [ 3796.173] (II) modeset(0): EDID vendor "DWE", prod id 8448 [ 3796.173] (II) modeset(0): Using hsync ranges from config file [ 3796.173] (II) modeset(0): Using vrefresh ranges from config file [ 3796.173] (II) modeset(0): Printing DDC gathered Modelines: [ 3796.173] (II) modeset(0): Modeline "1024x600"x0.0 50.25 1024 1068 1156 1344 600 603 609 625 +hsync -vsync (37.4 kHz eP) [ 3796.173] (II) modeset(0): Modeline "720x576"x0.0 27.00 720 732 796 864 576 581 586 625 -hsync -vsync (31.2 kHz e) [ 3796.173] (II) modeset(0): Modeline "1920x1080i"x0.0 74.25 1920 2008 2052 2200 1080 1084 1094 1125 interlace +hsync +vsync (33.8 kHz e) [ 3796.173] (II) modeset(0): Modeline "1920x1080i"x0.0 74.25 1920 2448 2492 2640 1080 1084 1094 1125 interlace +hsync +vsync (28.1 kHz e) [ 3796.173] (II) modeset(0): Modeline "1280x720"x0.0 74.25 1280 1720 1760 1980 720 725 730 750 +hsync +vsync (37.5 kHz e) [ 3796.173] (II) modeset(0): Modeline "1920x1080"x0.0 148.50 1920 2448 2492 2640 1080 1084 1089 1125 +hsync +vsync (56.2 kHz e) [ 3796.173] (II) modeset(0): Modeline "800x600"x0.0 40.00 800 840 968 1056 600 601 605 628 +hsync +vsync (37.9 kHz e) [ 3796.173] (II) modeset(0): Modeline "800x600"x0.0 36.00 800 824 896 1024 600 601 603 625 +hsync +vsync (35.2 kHz e) [ 3796.173] (II) modeset(0): Modeline "640x480"x0.0 31.50 640 656 720 840 480 481 484 500 -hsync -vsync (37.5 kHz e) [ 3796.173] (II) modeset(0): Modeline "640x480"x0.0 31.50 640 664 704 832 480 489 492 520 -hsync -vsync (37.9 kHz e) [ 3796.174] (II) modeset(0): Modeline "640x480"x0.0 25.18 640 656 752 800 480 490 492 525 -hsync -vsync (31.5 kHz e) [ 3796.174] (II) modeset(0): Modeline "720x400"x0.0 28.32 720 738 846 900 400 412 414 449 -hsync +vsync (31.5 kHz e) [ 3796.174] (II) modeset(0): Modeline "1280x1024"x0.0 135.00 1280 1296 1440 1688 1024 1025 1028 1066 +hsync +vsync (80.0 kHz e) [ 3796.174] (II) modeset(0): Modeline "1024x768"x0.0 78.75 1024 1040 1136 1312 768 769 772 800 +hsync +vsync (60.0 kHz e) [ 3796.174] (II) modeset(0): Modeline "1024x768"x0.0 75.00 1024 1048 1184 1328 768 771 777 806 -hsync -vsync (56.5 kHz e) [ 3796.174] (II) modeset(0): Modeline "1024x768"x0.0 65.00 1024 1048 1184 1344 768 771 777 806 -hsync -vsync (48.4 kHz e) [ 3796.174] (II) modeset(0): Modeline "832x624"x0.0 57.28 832 864 928 1152 624 625 628 667 -hsync -vsync (49.7 kHz e) [ 3796.174] (II) modeset(0): Modeline "800x600"x0.0 49.50 800 816 896 1056 600 601 604 625 +hsync +vsync (46.9 kHz e) [ 3796.174] (II) modeset(0): Modeline "800x600"x0.0 50.00 800 856 976 1040 600 637 643 666 +hsync +vsync (48.1 kHz e) [ 3796.174] (II) modeset(0): Modeline "1440x480i"x0.0 27.00 1440 1478 1602 1716 480 488 494 525 interlace -hsync -vsync (15.7 kHz e) [ 3796.174] (II) modeset(0): Modeline "1440x240"x0.0 27.00 1440 1478 1602 1716 240 244 247 262 -hsync -vsync (15.7 kHz e) [ 3796.174] (II) modeset(0): Modeline "720x480"x0.0 27.00 720 736 798 858 480 489 495 525 -hsync -vsync (31.5 kHz e) [ 3796.174] (II) modeset(0): Modeline "1280x720"x0.0 74.25 1280 1390 1430 1650 720 725 730 750 +hsync +vsync (45.0 kHz e) [ 3796.174] (II) modeset(0): Modeline "1440x576i"x0.0 27.00 1440 1464 1590 1728 576 580 586 625 interlace -hsync -vsync (15.6 kHz e) [ 3796.174] (II) modeset(0): Modeline "1440x288"x0.0 27.00 1440 1464 1590 1728 288 290 293 312 -hsync -vsync (15.6 kHz e) [ 3796.174] (II) modeset(0): Modeline "1920x1080"x0.0 74.25 1920 2558 2602 2750 1080 1084 1089 1125 +hsync +vsync (27.0 kHz e) Test with Tony's .deb After installation dpkg -i but before reboot: to http://ix.io/FbO root@tinkerboard:~# uname -a Linux tinkerboard 4.4.112-rockchip #34 SMP Tue Jan 30 22:34:04 EST 2018 armv7l armv7l armv7l GNU/Linux root@tinkerboard:~# lsmod Module Size Used by zram 28672 4 lz4_decompress 16384 1 zram lz4_compress 16384 1 zram 8723bs 1253376 0 no armbian-config... WiFi so I nmtui = it still works xrandr still doesn't work for both displays. HDMI-to-DVI 1280x1024 (SXGA) = it works but it came with 800*600 touch screen 1024x600 = it works full screen Thank you for the *.debs was pretty easy. Question, does tinker board use zram like @tkaiser and @zador.blood.stained had the discussion here: https://forum.armbian.com/topic/5565-zram-vs-swap/?do=findComment&comment=42739 ? Edited February 3, 2018 by Tido added zram question
TonyMac32 Posted February 4, 2018 Author Posted February 4, 2018 18 hours ago, bedalus said: I think maybe the issue is that it's a 4K TV. I didn't have any issues with my old HD TV, but we got rid of it! Any config changes I can apply after flashing the image so I get an output? Sorry I missed this, that shouldn't be the issue, I've started it on both HD and 4K without issue. The display issue I've had involves changing from 4k to another resolution and the DRM system crashing. Did you install all of the debs, and remove the old kernel packages? 4 hours ago, Tido said: Question, does tinker board use zram It was rolled out at the same time as the others, and shows up in your "lsmod" output as a loaded module. That's about all I know. 4 hours ago, Tido said: Touch screen 1024x600 = it works full screen (touch I did not test) who's display is that? I only have the RPi one at 800x480. 15 hours ago, stefan.steffens said: I'd like to test too but can someone please tell me which option I'm supposed to pick: Stefan, I just wanted to make sure you had cloned my fork of the Armbian build system, and then check to make sure I answered your question well enough.
Tido Posted February 4, 2018 Posted February 4, 2018 5 hours ago, TonyMac32 said: who's display is that? I only have the RPi one at 800x480. 7 inch 1024*600 Display Capacitive Touch Screen One day it shall become the control display to my music-player in the living room. I expected to use it with RPi in the worst case, because it shall work with it 'out of the box' after some configurations.. however it didn't fill the whole display, but touch just works. The controller board can also be used for other displays, but cautions or customization is recommended: Spoiler PCB800099 – RTD2660/RTD2662 based LCD Controller Review “PCB800099”, also known as VS-TY2662-V1 is an LCD controller PCB which has entered the market relatively recently. As per usual I have no idea who designed either the board or who wrote its software, but I do know it is based on the Realtek RTD2662 controller, although some may be labelled RTD2660 (which in theory means no HDMI), but if your HDMI input works, it’s an RTD2662. This is just sloppy chip labelling. The RTD266x family represents Realtek’s “TV” lineup, and using this, you notice it. http://tech.mattmillman.com/lcd/pcb800099/ you can hack EDID if it doesn‘t fit. VS-TY2662L-V1 is a LCD control board, it supports between 7 and 22 inch LCD panel with single /dual LVDS interface. Powering DC 5V or 12V TWO-IN-ONE adapter (12V recommended) Inverter Board CONNECTOR / Back-light ON/OFF control / Pin 3 Getting too hot and fails They often will fail after several hours of use and I figured out why: people are connecting their LCD backlights to the 3.3V logic supply and this is pulling far more current through the 3.3V domain than its built for. The inductor coil on the switching power supply reaches over 140°C (290ºF) after about 45 minutes when using my 7“ 1280×800 (WXGA), IPS (HSD070PWW1) no touch and then this causes downstream components to be damaged. I found that seems to work (although haven’t tested it as much) is to replace the inductor coil (82uH) with one which can handle over 2A. I replaced it with AIUR-06-820K off digikey and this doesn’t get anywhere near as hot.
stefan.steffens Posted February 4, 2018 Posted February 4, 2018 7 hours ago, TonyMac32 said: Sorry I missed this, that shouldn't be the issue, I've started it on both HD and 4K without issue. The display issue I've had involves changing from 4k to another resolution and the DRM system crashing. Did you install all of the debs, and remove the old kernel packages? It was rolled out at the same time as the others, and shows up in your "lsmod" output as a loaded module. That's about all I know. who's display is that? I only have the RPi one at 800x480. Stefan, I just wanted to make sure you had cloned my fork of the Armbian build system, and then check to make sure I answered your question well enough. Hi Tony, I downloaded from git clone https://github.com/Tonymac32/build.git cd build ./compile.sh successfully generated 'Welcome to ARMBIAN 5.40 user-built Ubuntu 16.04.3 LTS 4.4.112-rockchip' which I hope is the correct one but after successful boot ran into the first problem of not being able to mount a CIFS (NFS mounts if you remember always crashed the system under load) and I'm getting the error message 'mount error: cifs filesystem not supported by the system' even though I loaded the CIFS-Utils. Is CIFS not included in the kernel?
martinayotte Posted February 4, 2018 Posted February 4, 2018 Check if you have the kernel module with : find /lib/modules -name cifs.ko
stefan.steffens Posted February 4, 2018 Posted February 4, 2018 47 minutes ago, martinayotte said: Check if you have the kernel module with : find /lib/modules -name cifs.ko no, it's missing. But I found it under File systems > Network File Systems and selected the respective options :-)
JMCC Posted February 4, 2018 Posted February 4, 2018 +1 for the decision to switch to the Rockchip kernel. It is under very active development (several commits a week), and incorporating all that work into Armbian would be a great asset. However, they are also developing different kind of stuff related to video HW acceleration (GLES libraries, X server, gstreamer, mplayer, kodi, etc.), but they only support Debian Stretch in their releases. I suggest to switch to Stretch for the default image, so we can also take advantage of that too.
TonyMac32 Posted February 4, 2018 Author Posted February 4, 2018 1 hour ago, JMCC said: I suggest to switch to Stretch for the default image, so we can also take advantage of that too. Stretch has demonstrated it's own set of issues, but it is available if you wish to build it yourself. My last test was certainly more promising than in the past, a few months ago it would lock up for approximately 20 seconds while loading apps like web browsers or LibreOffice. Now it is still glitchy but does not hang. 4 hours ago, stefan.steffens said: I found it under File systems > Network File Systems and selected the respective options Strange that is was unselected, I'll update that, or you can put in a pull request. updated in build system
stefan.steffens Posted February 5, 2018 Posted February 5, 2018 19 hours ago, TonyMac32 said: Stretch has demonstrated it's own set of issues, but it is available if you wish to build it yourself. My last test was certainly more promising than in the past, a few months ago it would lock up for approximately 20 seconds while loading apps like web browsers or LibreOffice. Now it is still glitchy but does not hang. Strange that is was unselected, I'll update that, or you can put in a pull request. Some great news to share while testing continues: with the old kernel I easily could freeze the tinkerboard so that I couldn't connect anymore when putting high load on NFS mounted shares (100 Mbps and 1 Gbps). With this new kernel the NFS mount ist stable!! I've got two compiles running in parallel via SSH sessions via 100 Mbps for > 1h with CPU load > 3 @ 1800 Mhz with 70 C. That's impressive so I'm no longer worrying about CiFS Unfortunately using 1 Gbps it crashed again so still some work to be done :-(
TonyMac32 Posted February 6, 2018 Author Posted February 6, 2018 16 hours ago, stefan.steffens said: Unfortunately using 1 Gbps it crashed again so still some work to be done :-( I will need to experiment with something that ayufan rolled out for the Rock64 to tune the timings on GbE, that could cause the network to fail (Rock64 has/had some GbE instability as well) In the meantime, updated the available packages with current state of my fork, Rockchip repo updated to 4.4.112, I've patched to 4.4.115, however a couple chunks did not patch in properly and a couple claimed to already be in place, so not 100%
stefan.steffens Posted February 6, 2018 Posted February 6, 2018 (edited) 5 hours ago, TonyMac32 said: I will need to experiment with something that ayufan rolled out for the Rock64 to tune the timings on GbE, that could cause the network to fail (Rock64 has/had some GbE instability as well) In the meantime, updated the available packages with current state of my fork, Rockchip repo updated to 4.4.112, I've patched to 4.4.115, however a couple chunks did not patch in properly and a couple claimed to already be in place, so not 100% That would be great. The current kernel doesn't support SMB2 and later. I'll put in a pull request to get this changed as SMB1 is outdated Edited February 6, 2018 by stefan.steffens
Tido Posted February 6, 2018 Posted February 6, 2018 13 hours ago, TonyMac32 said: to tune the timings on GbE some weeks ago I read about a guy who took the code (script) from TK and tweaked it even further to check different settings for Ethernet automagically hmmm.. I can't remember the name. Does someone else know it ?
TonyMac32 Posted February 6, 2018 Author Posted February 6, 2018 Yes, Ayufan. ;-). I am working with that script now , some limited success so far (about 20 minutes invested)Sent from my Pixel using Tapatalk
Igor Posted February 6, 2018 Posted February 6, 2018 Shell we also unify DTB across kernels? rk3288-tinker.dtb is now in mainline and we are adding rk3288-miniarm.dtb there ... backward compatibility can be solved within bootscript. What do you think?
Recommended Posts