Naguissa

Hi!
 
Yesterday i upgraded ugly Chinese linux to Armbian 16.04 LTS and tested h3control on it. All, except daemon installer, worked fine. Now daemon installer had been fixed. I need any help in testing of it on H3/H2/H5 boards with legacy/mainline kernels.
 
h3control - is a headless daemon/console tool to check and control CPU, DDR frequency and built-in temperature sensor via embedded http-server.
It distinguishes from Armbian tools (h3's consumption and monitor):
It doesn't rely on particular linux distribution. The only prerequisite is a mono. It tested with mono from 3.2.8 (released in Feb 2014) to 5.4 (current stable). It is a web app. App was designed for compatibility with many-years-old mobile tablets/phones. Built-in browsers from Android 4+ and iOS 7+ are fully supported.  
Here are two kinds of one-line installers:
- launch h3control in terminal:
wget -q -nv -O - https://github.com/devizer/h3control-bin/raw/master/public/h3control.sh | bash - install and launch h3control daemon:
wget -q -nv -O - https://github.com/devizer/h3control-bin/raw/master/public/h3control-install-daemon.sh | bash links: 
User/Install Guide and screenshots: https://github.com/devizer/h3control-bin
History and Whats New: https://github.com/devizer/h3control-bin/blob/master/WHATS-NEW.md
First topic on Orange PI forum: http://www.orangepi.org/orangepibbsen/forum.php?mod=viewthread&tid=645
Source code: https://github.com/devizer/h3control
 
picture: 
 
Looking forward for feedback
Vlad
 
P.S. Please install mono first: apt-get install mono-complete

i dont think it would help (maybe on a Raspberry where one USB Port has a power limit).
If you got the right power-supply it can work (for a 2.5" HDD and not a 3.5" HDD) - but I would be much better if the HDD has its own power supply.
With the 2 plug-cable you could try to plug the data/power connector to the Prime and the second power only to a additional power supply.
But the best will be a seperate power supply for the drive and a normal one plug cable.

Wish to add s5p6818 to the Armbian exists and we did some small progress on this. There is one image for Nanopi M3 and a kernel 4.4.y showed up (untested) recently for those chips ... beside stock 3.4.y which is too old to deal with and officially EOL. 
 

More people on the project helps more than cash here and there. Our group is small and a lot of work is expected to get this chip/those boards on a decent level. If there will be just a few people dealing with s5p6818, progress will remain slow.

Hi,
 
I've been struggling also with all the info in this thread but finally succeeded to make decompile/edit/compile the dtb file (assume this file as BIOS for ARM  )
I'm putting all commands here as reference for me as well :
 
cd /boot/dtb sudo cp sun8i-h3-orangepi-one.dtb sun8i-h3-orangepi-one.dtb.old sudo dtc -I dtb -O dts -o sun8i-h3-orangepi-one.dts sun8i-h3-orangepi-one.dtb sudo sed -i -e 's/dr_mode = "otg";/dr_mode = "host";/g' sun8i-h3-orangepi-one.dts sudo dtc -I dts -O dtb -o sun8i-h3-orangepi-one.dtb sun8i-h3-orangepi-one.dts Explanation of different lines:
 
1. go to dtb directory
2. make backup of the compiled file in case something goes wrong
3. decompile the file to be able to alter it with text editor
4. change the string from "otg" to "host"
5. compile the altered file back to binary format dtb
 
 
The only bad thing with all this above is that if you upgrade your kernel the info will be lost so you have to do it again.
I don't get why this parameter is set by default to "otg"?

I just open-sourced some code to replace fbtft and fbcp. It uses dirty-tiles to try to minimize the writes to the SPI LCD and improve the framerate. I'm working with some of the guys at sudomod to get it working on Lakka builds too. You can download it here:
 
https://github.com/bitbank2/BB-CP
 
 

This thread gets a bit out of control...  So let's see if we bring this thread a bit more productive.
 
You explained now at minimum two times that you can't provide sudo armbianmonitor -u from your first build cause you didn't have this image anymore.  But since the 'stable' build you use still crashes, you could provide it for this build? 
Printscreens are the last chance when armbianmonitor isn't possible at all (board doesn't boot or upload fails for whatever reason).  As @tkaiser pointed out here ,  he as an experienced SBC user gets much more Information from armbianmonitor than from printscreens.
 
A reminder back for you (you should see before your first post):
 
He might be a little bit harsh but when he several times ask for something and you deliver everything else but not the things he wants he might be a bit annoyed. Others would stop answering your question cause they thought it's a 'waste of time'... 
My personal opinion: It's up to you. If you can't deal with 'harsh' answers, solve it by your self or hope that somebody else joins this thread to help you. But @tkaiser knows those SBCs best better than most of us for server use cases (not that I wanna upset others) and it might be a good idea to follow his advice. 
 

Not to me. USB hub by itself is a very light load but it results in a measurable voltage drop on DC IN. And I have a couple of USB hubs that can reboot a microUSB powered RPi if you connect them - most likely because of a filtering capacitor on the input causing a large enough current spike.

http://sprunge.us/eiFf
There are no problems with Armbian. Bananapi M1 + USB hub + AC Wireless access point. Connected at boot time or later, in any case, it works perfectly fine. 

Armbian is not responsible for hardware design failures. Either use powered USB hub or some other board.
 
 

Right, thanks. I've got two of them today (similar ones, but having different weight) and so far so good - tested them both with few older 2,5" & 3,5" disks around and no problems in few hours of stress tests.
So, now I think I'll buy 4TB WD Red 3,5" disk :-)

UPDATE: DID IT! A LONG TIME AGO (AND WASN'T ABLE TO COME BACK TO IMMEDIATELY UPDATE EVERYONE)
For those who are about to ask for the same question on the internet this is the answer.
 
I used hd-idle and it worked perfectly among my drives.
 
follow this guide:
https://www.htpcguides.com/spin-down-and-manage-hard-drive-power-on-raspberry-pi/
 
ymmv depending on the drives you use (if the hard drives can support it)
 
hd-idle perfectly worked on my old western digital and seagate hard drives but not perfectly on my seagate barracuda green hard drives (I think because of power management within the firmware of my hard drive so I had to turn off hd-idle altogether)
 
you can find on the link other alternatives to the one I used in case it didn't work for you
 
thanks for everyone who answered my inquiries!

Got some nice feedback from JMicron explaining firmware versions.
0.1.x is for self-powered SATA HDD/SSD device 0.2.x is for bus-powered SATA HDD/SSD device  0.4.x is for self-powered SATA HDD/SSD/ODD device application (ODD --> optical disk) $higher-number.x means custom firmware (enclosure maker) I only asked for the firmware revisions of a couple of devices I've access to so not all possible variations are listed above (eg. 0.3.x or 0.5.x could mean 'bus-powered HDD/SSD/ODD device). But at least this explains a lot already.
 
When comparing 0.1.0.5 on ODROID HC1 and 0.4.0.5 with ROCK64 SATA cable the firmware revision (x.x.0.5) is the same while the ROCK64 cable firmware should also deal with optical drives. And the 0.2.x firmware being meant for bus-powered vs. self-powered suddenly explains the different behaviour I observed wrt JMS chip being present on the USB bus or not depending on whether there's a SATA drive connected or not (different consumption in different modes).
 
Anyway that needs some more understanding and testing but at least we don't need to be concerned about one JMS578 device (ODROID HC1) having a horribly outdated firmware 0.1.0.5 while ROCK64 SATA cable has a way higher (0.4.0.5) since FW revision is actually the same.
 
JMicron is still busy testing with a newer firmware revision solving the HDD spindown issues, once I get news or something to test I'll update this thread.

Little update on the NAS Expansion board: the first time I had this thing in my hands and gave it a try with mainline kernel I was surprised why the JMS578 chips on the board did not allow to use UAS. It looked always like this (lsusb -t):
/: Bus 04.Port 1: Dev 1, Class=root_hub, Driver=ehci-platform/1p, 480M |__ Port 1: Dev 2, If 0, Class=Mass Storage, Driver=usb-storage, 480M With no other JMS578 device around I experienced this and since I'm currently testing with Orange Pi Zero Plus (still no UAS) and In the meantime JMicron provided us with a firmware update tool.... I thought I take the slightly higher JMS578 firmware revision from ROCK64 SATA cable (0.4.0.5) and update the NAS Expansion board (0.4.0.4) with:
root@orangepizeroplus:~/JMS578FwUpdater# ./JMS578FwUpdate -d /dev/sda -v Bridge Firmware Version: v0.4.0.4 root@orangepizeroplus:~/JMS578FwUpdater# ./JMS578FwUpdate -d /dev/sdb -v Bridge Firmware Version: v0.4.0.5 root@orangepizeroplus:~/JMS578FwUpdater# ./JMS578FwUpdate -d /dev/sdb -b ./JMSv0.4.0.5.bin Backup Firmware file name: ./JMSv0.4.0.5.bin Backup the ROM code sucessfully. Open File Error!! root@orangepizeroplus:~/JMS578FwUpdater# ./JMS578FwUpdate -d /dev/sda -f ./JMSv0.4.0.5.bin -b ./JMSv0.4.0.4.bin Update Firmware file name: ./JMSv0.4.0.5.bin Backup Firmware file name: ./JMSv0.4.0.4.bin Backup the ROM code sucessfully. Programming & Compare Success!! Success!
/: Bus 04.Port 1: Dev 1, Class=root_hub, Driver=ehci-platform/1p, 480M |__ Port 1: Dev 2, If 0, Class=Mass Storage, Driver=uas, 480M Please keep in mind that you need to update both JMS578 of course. I won't upload the newer firmware yet since thanks to Pine's TL Lim I'm in direct contact to JMicron now and it's about fixing another JMS578 firmware issue.

I'm currently working on a fork of the pyA20 python library which is used quite often by people here when playing with GPIO, spi or i2c. It's not ready for public at the moment, but it will be soon.  It has an automated board detection, pin naming is consistent so that you can use your python scripts on every supported board without renaming everything. And it has a 'board detection' mechanism to use the right pin mapping during the installation. 

That's important to know. In fact we try to not be any popular just to avoid dealing with people rejecting reality and showing a bizarre attitude
 
And now let's stop, you've been asked helping us diagnosing a rare issue, you refused to, now go choose another distro and be happy with whatever you will do.
 
BTW: the only reason I answered is since the threads here in this subforum can help other users stop rejecting reality and to realize that low-level hardware issues (using ultra slow SD cards -- we block booting from such crap by intention and it's not that hard to understand why) can't be solved one layer above. Life's just too short to deal with this.

To stop wasting my and other's time on this boring 'issue' here a final summary:
Close to unbelievable but after another 'evil tkaiser attacking us' event today the hardware vendor 'fixed' voltage regulation description. Just to remind you: this file has to be correct in the first place, there's no excuse for such wrong information there, it's simply the hardware vendor describing how the board works. So now that PL01 is used for voltage regulation (now in conflict with another active PL01 entry for s_rsb_sda -- good luck!) only all gmac* entries are still wrong and cooler_table not using the 912 MHz OPP is most probably a great recipe for poor performance when overheating occurs. So in case someone from SinoVoip wants to fix their pseudo Armbian build it would be wise to fix the fex first since afterwards Armbian's h3consumption tool can work without issues (today not due to still wrong fex file) On their Gitbook pages the size of M2 Zero increased by 5mm (now at least this most basic info is correct), most of the other 'information' is still sparse, wrong, missing, bogus. But fortunately the hardware is still too small on their product page and of course soon everywhere around the globe in advertisements and product listings since all resellers use the wrong dimensions they've been provided with back in July. So anyone interested in this board running with the outdated legacy kernel: chances are great that you get a working OS image over at bananapi.org (soon). As a reminder: Armbian follows the policy to not officially support Raspberry Pi boards which of course also applies to deliberately compatible looking but mostly incompatible RPi clones like this M2 Zero here (we don't want to see this forum/community dying when RPi users or fooled M2 Zero customers arrive) Armbian also tries to phase out legacy kernel support (3.4.113 which is not supported any longer since over half a year now). CSI/camera support with mainline kernel is still WiP so when switching from legacy to mainline camera functionality will also be missing. Again no reason to officially support such a device Third 'problem': dishonest advertising. Nowhere is mentioned by the vendor that M2 Zero is totally incompatible to RPi cameras (which is something average buyers expect) and RPi software (which is something clueless buyers expect from something that mimics the look of an RPi Zero and is said to run 'Raspberry Pi image'). There's really no reason for us here wasting our spare time with support efforts like this: https://forum.armbian.com/topic/5579-power-off-with-hdd-over-active-hub/?do=findComment&comment=43088  
Exactly. @Lion Wang's problem is that he wants to sell hardware and his company earned a very negative reputation over the last years (believing this would be caused only by evil people outside and not related to their internal and pretty real problems). That's something where some idiots here at Armbian could help working for him in their spare time and doing his software and support work.
 
@lvmc has the problem that he wants to use this BPi board with his own camera modules. Should work now so let's please stop babbling about community and so on.
 
We have the problem that even if we wanted to support SinoVoip products they don't allow us. They refuse to cooperate, do not provide correct hardware descriptions, do not listen to community, delete community knowledge, ignore(d) even patches they got for free just due to ignorance, ignorance, ignorance.
 
A few people here suggested to give SinoVoip a final chance. I support this. The problem is... I and others are dealing with Banana madness now in the 3rd year. We have heard that so often that it simply got too boring. So let's step back now, give them 6 months of time to show that they're willing to improve, deal with their internal ignorance/stupidity problems and then let's have a look again.
 
In the meantime it would be great if people would stop asking us for anything Banana related. Thank you.
 
 

It's not about last chance, I think you missed a key point there.  Support for a new board is mostly a question of time and knowledge of an experienced developer taking care of a SBC.  When you've a look which BPi boards are supported with a 'stable' armbian. You could see that there are a few of there boards:
BPi M2+ (H3) BPi M2 (A31s)
BPi Pro (A20, actually a lemaker, not SinoVoip product, correct me if I'm wrong here...)
BPi + (I think this is called M1+ by SinoVoip, also a A20)
BPi (should be the one called M1 by SinoVoip, A20)
 
IMO, the reason why you see so much more OPi boards supported by Armbian is the following: They have a real conservative 'board design philosophy' - more or less every board from xunlong is based on H2+/H3 which as Thomas said, makes it easy to add support (as long as you've correct schematics, or as xunlong does it 'never change a winning team' - you know one, you know most OPIs ).  SinoVoips approach to invent '20 different wheels for 15 use cases' (means having a bunch of different SoCs on their SBCs,  and therefore many different board designs make it harder to support their boards).  
 
I bought a BPi Zero (and paid the full price  ) and I'm sure that I'll have a dedicated armbian running on it (I think I'm able to adjust the basic things I need to get my needs running if nobody from the 'core developers' are willing to do it) but I'm not able and passionate enough to be a 'maintainer' like @TonyMac32 for the tinkerboard (actually a board which has also a lot of design flaws ). Means I'll not spend much time on things I'm not interested in and I don't feel responsible to answer every question about it on the armbian forum.  Naming your images Raspian (something Xunlong and SinoVoip do) is IMO false advertising. First their boards are not RPIs. Second, Raspian is built on a (more or less) recent kernel (at least 4.x). Third, GPIO libraries  are working out of the box (which is often not true for these boards) and last, things like mathematica,  Node-Red & Wolfram Alpha works also out of the box (I never checked all these things on the OPis or BPis Raspians, but for the kernel it's sure - most OPis running the outdated 3.4.39 kernel BPi0 improved here slightly with a 3.4.113 kernel). Both companies don't shine on software support (but Xunglongs 'conservative design strategy' makes it easier to support their boards), so improvement there would be really appreciated.
 
Annotation: this part of my post has some sort of humor, sarcasm & frustration in it, if you can't deal with it, just don't read it.  
A basic 'board bring up' for an H2+/H3 board (as repeated a way to often in this thread  ) is not a huge deal. But maintaining the community support clearly is (just have a look here how many questions come up for *random SBC*). More or less every week a thread 'why wifi on OPi0 does not work?' (shitty XR819 just use search engine) or 'why armbian does not support RPi display on tinkerboard?' (armbian is not the board maker, this is a spare time 'job' we don't have time to do everything in minutes,  btw. congrats to @tonymac32, you got it work! I think we're now close to ASUS advertised RPi compatibility with the tinker ).  So, the more boards armbian supports, the more time experienced supporters of armbian are absorbed by answering this questions, testing images etc. (Thomas would say, 'waisting time'  ).  And what's also clear,  the more a board is claimed to be raspberry compatible, the more 'inexperienced users' joining armbian (best example Tinkerboard).  This might avoid someone like Thomas being excited adding support for such a board cause he knows the consequences - more 'inexperienced users' (sometimes too ignorant following basic instructions from an experienced armbian supporter -  see here for some examples), expecting that everything on armbian should work similar than on raspian cause boardmaker claimed RPi compatibility and armbian is based on debian. So, 'no difference to *random RPi*'  (except, it has to be cheaper than a RPi and I want 'real SATA' on my board).  That's why I still like the RPi - more or less everything they advertise works on their boards. It's not the most powerful board (you get more powerful & cheaper SBCs on an H2+/H3 basis) but most things the *average SBC user* can imagine is solved by someone from the RPi world and they've targeted the 'noob problems' (it's a shame that they still use the micro USB connector for the RPi3 but nevertheless they have a 'protection mechanism' to avoid underpowering the board - one major issue on cheap H2+/H3 boards here at armbian). 
I hope you see the point in all this *random BS I talk here*
Board bring up would be easy Support needs a lot of time more *average RPi users* means more ignorant users (not all of them, but part of them are) the more a bord is claimed to be 'RPi compatible' the more *average RPi users* will show up here - the more time is needed to explain to them that verdor claimed RPi compatibility doesn't mean that this is true nor armbians major goal is to be 'RPi compatible'  
Seems that they run out of their 'good eMMC' chips.   (maybe I should sell my 'old' OPi Pc+ on ebay, advertising that it is a 'fast one'  ). 
 
IMHO no! The only reason using NanoPi Duos 'motherboard' is during product development to get 'all features' easily accessible. If you still use it 'on production scale' of your project, just go for an *random H2+/H3 SBC* which deploys this features without a 'motherboard'. The main benefit of those SBCs is their size with a drawback that not everything is deployed on the board (this could also be a benefit if you don't want to have things deployed on the place the boardmaker deploys it, e.g. ETH is deployed 'on the false edge' for your project). But this is clearly a personal opinion....  
 
@Lion Wang - take care of this sort of feedback. At the moment, your BPi zero is a 'quad-core rip off' of the RPi 0 for a higher price than the original which would make it hard for most SBC customers to buy it instead of the 'original'. The fact that the camera connector is not compatible to RPi makes it even worse for a lot of use cases (you'll find a generic RPi compatible camera for ~6$ on aliexpress but a BPi compatible camera is in the range of 20$).  RPis videocore GPU works on recent kernels whereas Mali is 'work in progress' (but to my knowledge, nobody works really on it.  ).  So, your board needs some 'features' which makes it interesting for people which are annoyed by the RPi0. This could be (personal opinion).
eMMC instead of/combined with SD card  ETH on a pinheader (which you have) more than one USB port (maybe also on a pin-header) etc.  I said it once and now the second time,  don't bring this discussion to personal level between you and him which will end similar to the 'famous' BPi-R2 thread we had here and @Tido or myself will close it cause it's only about you don't understand why Thomas doesn't like your products and you're claiming that he must work for Xunlong.  This thread is a little bit like a baseball game - a lot of boring, not BPi0 related, stuff (maybe also provided by myself  ), and some new information we didn't know before (e.g. ETH is accessible through pin-header, 1.1/1.3V cpu regulation is on PL1 instead of PL6, first version of schematics). But as a real American @TonyMac32 can explain to you what happens in baseball after strike two...  (hint:  I'll close the thread maybe only for a 'cool down time' maybe forever cause I don't think we need a second 'BPi-R2 thread' again).  If you felt upset by Thomas and you can't deal with it, ignore him. If you're smart you 'extract' the key concerns he has about your product/company and evaluate if it's worth to improve/adapt it. 

I got to modify my smb.conf file last night.  I removed the security and map to guest settings.  I also noticed in
RagnerBG's example that the folder name had to be in the path and the brackets above the stanza (i think that is the proper term).  So I modified that as well.
 
I now have access from a Windows machine and am starting to move files from my old Windows 7 machine serving files to my OrangePI PC server!!
 
Thanks for the help!
 
Here is my modified section:
[global] netbios name = opiserver server string = My Samba Share %v [OPants] comment = Orange Pi PC Server Share path = /media/mickey/OPants browseable = yes writeable = yes read only = no guest ok = yes  

Hi,
 
I noticed OrangePi have started selling a 7" lcd with an hdmi adapter. It's only 1000x600 (which might be an awkward resolution to get working with some SBCs) but I thought I'd give one a try. This might fit into my farm build as a dedicated status monitor or something
It's 22 usd plus shipping:
https://www.aliexpress.com/item/7inch-TFT-LCD-Screen-for-Orange-Pi-H3-chip-Boards/32831758014.html

If you're talking about Serial Number of the CPU (SID), which is used to build MAC address, you can see it in /proc/cpuinfo on Mainline kernel (I don't know if Legacy is also providing it).

@TonyMac32 thanks!
 
Steps to use the ds3231 as system clock:
 
1) Add "echo ds1307 0x68 > /sys/class/i2c-adapter/i2c-1/new-device" to /etc/rc.local (if needed and above "exit 0")
2) In /lib/udev/hwclock-set comment out the following:
if [ -e /run/systemd/system ] ; then exit 0 fi if [ -e /run/udev/hwclock-set ]; then exit 0 fi then change the HCTOSYS_DEVICE=rtc0 to be HCTOSYS_DEVICE=rtc1
3)In /lib/udev/rules.d/50-udev-default.rules change the SUBSYSTEM=="rtc" line to:
SUBSYSTEM=="rtc", KERNEL=="rtc1", SYMLINK+="rtc", OPTIONS+="link_priority=-100" 4) In your hwclock udev rule make sure you have (/lib/udev/rules.d/85-hwclock.rules):
KERNEL=="rtc1", RUN+="/lib/udev/hwclock-set $root/$name"  

Extra sanity check, did you connect the RTC Ground to pin4 on the tinker?
 
Also you dont have the rtc-ds1307 kernel module loaded. If you reboot clean and "modprobe rtc-ds1307" does /dev/rtc1 appear without the "echo ds1307 0x68 > /sys/class/i2c-adapter/i2c-1/new-device"?
 
If yes to both then the next steps for setup are easy.

https://docs.armbian.com/User-Guide_Allwinner_overlays/

usb@01c13000 {
            compatible = "allwinner,sun4i-a10-musb";
            reg = <0x1c13000 0x400>;
            clocks = <0x4 0x0>;
            interrupts = <0x0 0x26 0x4>;
            interrupt-names = "mc";
            phys = <0x2b 0x0>;
            phy-names = "usb";
            extcon = <0x2b 0x0>;
            allwinner,sram = <0x2c 0x1>;
            status = "okay";
            dr_mode = "host";
            linux,phandle = <0x61>;
            phandle = <0x61>;
 
        phy@01c13400 {
            #phy-cells = <0x1>;
            compatible = "allwinner,sun7i-a20-usb-phy";
            reg = <0x1c13400 0x10 0x1c14800 0x4 0x1c1c800 0x4>;
            reg-names = "phy_ctrl", "pmu1", "pmu2";
            clocks = <0x2d 0x8>;
            clock-names = "usb_phy";
            resets = <0x2d 0x0 0x2d 0x1 0x2d 0x2>;
            reset-names = "usb0_reset", "usb1_reset", "usb2_reset";
            status = "okay";
            pinctrl-names = "default";
            pinctrl-0 = <0x2e>;
            usb0_id_det-gpio = <0x25 0x7 0x3 0x0>;
            usb0_vbus_power-supply = <0x2f>;
            usb0_vbus-supply = <0x30>;
            linux,phandle = <0x2b>;
            phandle = <0x2b>;
 

    usb0-vbus {
        compatible = "regulator-fixed";
        pinctrl-names = "default";
        pinctrl-0 = <0x49>;
        regulator-name = "usb0-vbus";
        regulator-min-microvolt = <0x4c4b40>;
        regulator-max-microvolt = <0x4c4b40>;
        enable-active-high;
        gpio = <0x25 0x1 0x9 0x0>;
        status = "okay";
        linux,phandle = <0x30>;
        phandle = <0x30>;
 
The file has several differences throughout compared to the armbian version. These are just a few of note. The values for some of the above properties are different in the default file vs the SimpleNAS dtb I used. I don't believe the OTG port was getting power before. There are other property differences throughout and everything appears to be working without issue.
 
 

Which is not possible with all Mali GPUs Allwinner used till H6.

Try toggling: https://github.com/armbian/build/blob/master/config/fex/orangepizero.fex#L504
 
 
Afaik it should work. Perhaps unloading is not working as it should. This kernel is from some other times ... removal from /etc/modules and reboot might be needed.
 
Nobody is working on H3 legacy kernels anymore  Modern kernel will be here soon.
 
@Abdullah Seba Technical support is our free will. Our expense and we tend to rest on Sundays.