Fourdee

Members
  • Content Count

    22
  • Joined

  • Last visited

About Fourdee

  • Rank
    Member

Recent Profile Visitors

812 profile views
  1. Igor, Thank you for opening up and allowing me to understand you, and, the way in which your project is allowed to operate. We clearly have a different level of comprehension and expected professionalism, which unfortunately, can not be met in the middle. I believe there is nothing that can be gained from further discussion. In the interest of both our projects, I will remove all ARMbian based images from the DietPi lineup. You can view the status of this in the following link: https://github.com/Fourdee/DietPi/issues/1537 My only hope, is that you can find a higher level of solace and satisfaction, solely in the work you and your team do, on your project. I wish you all the best luck.
  2. I completely understand, as I also experience this first hand with DietPi. Its not easy doing something for nothing, especially when the joy factor which drives everything, is destroyed by those frustrations. Although we don't do kernel work, our support software titles require constant maintenance and adjustments due to changes outside of our control. Because as well know too well, Linux is not a constant, its always evolving and one line of code changed can break everything that depended on it. I envy and appreciate what you guys have achieved for those devices, and, highly respect what you have done for all the devices you offer. Allowing us all to enjoy a better experience and stability, not offered by the people who sell the device and profit from it. Without your efforts, those devices would probably have vastly reduced sales figures and a community lost without purpose. Both our projects are great and we should all be proud of what we have achieved, even when the days of frustration set in. In terms of recent events, I believe both our projects can benefit from showing a higher level of professionalism and respect that works both ways, and, not use each other to vent frustrations (which in turn only adds to them). I'll make a start:
  3. Sorry you feel that way Igor. It was never our intention to take over the work you guys do with ARMbian. It is our intention, to use your ARMbian opensource build tools, which allows us to generate an initial image, then optimize and configure it for DietPi. We then release it to our end users (with full credit to ARMbian in the DietPi login banner). Without which, we would need to revert to non-ARMbian based images. If anything, DietPi is promoting the work you are doing, in a different end-user experience and format. Our efforts and skills are not in kernel devolpment, its not what we do, and, we do not try to hide that. We therefore only support non-kernel related issues (which are out of our control and ability). In our ARMbian built images, Kernel updates are still handled by ARMbian repo using APT. I believe the issue here is your team generally dislike what DietPi offers to end users. Sorry, but we will not change that. If there is a bigger issue here of controlling who uses ARMbian build tools: Maybe it would be a suggestion to remove this software from the Open source scene, removing the chance of potential users of your software being disrespected over twitter and forums by your devolpment team for years on end. Its literally childish non-sense and I will not stand for it (hence the ARMbian + DietPi comparison, created due to TK's provoked actions on twitter). Regardless of the above and recent non-sense. I appreciate the work you guys do with ARMbian. I've always said that, even to the extent that i've donated to your project previously. But this unprofessional non-sense that we are all to blame for, has to end.
  4. @zador.blood.stained Thank you for the info, much appreciated!
  5. Hi, Apologies for bringing up an old topic. Has anyone been successful obtaining a working HDMI audio output with BPi Pro + Mainline 4.9? I tried various mixer settings, 3.5mm works fine, but not HDMI. Thanks.
  6. Thomas, If you can clearly define an issue with DietPi and/or its security, please make a git ticket and we will look into it. In the mean time, I will continue to delete all "hear say" posts with no relevant proof of your claims. It would also be worth noting, that, only your posts have ever been deleted, in the history of DietPi project.
  7. We have a system in DietPi that allows users to pre-enter their wifi details in /boot/dietpi.txt before powering on. By default, all DietPi images have all networking disabled, then this code runs after resize: https://github.com/Fourdee/DietPi/blob/master/dietpi/boot#L115-L213 Config file, located on FAT partition: https://github.com/Fourdee/DietPi/blob/master/dietpi.txt#L4-L24 Default /etc/network/interfaces: https://github.com/Fourdee/DietPi/blob/master/dietpi/conf/network_interfaces So, ARMbian could have a similar system, config /boot/armbian.txt, loaded during 1st run. I'll fork ARMbian and add this system in. Yep, have to hand it to RPi, although ARMv6 package and Repo, compatibility and simplicity across all their devices is exceptional. I'll take a look at your notes for your prototype installer, thanks for sharing. Although, if i'am honest, might be out of my depth at the moment. When it comes to uboot/initrd, I use ARMbian to sort it out lol
  8. Well, that answers that question then. Thanks for info http://dietpi.com/ Lightweight justice for your single-board computer. Optimized | Simplified | For everyone Kernel 4.x+: Tried a few months back with various boards using ARMbian build tools. Devices wouldn't boot. Haven't tried since. If I remember correctly. Your website used to list issues when using the "vanilla kernel", reduced support and features? Put me off trying further. ondemand is wrong for Allwinner BSP kernels: One could say, Allwinner H3 is wrong . On your experience, is interactive "right" for Allwinner?
  9. Hi all, I'am looking at creating a single unified H3 DietPi image (currently using ARMbian build tools), rather than one for each board. Would allow us to support all H3 devices, reduce work load and simplify DietPi source code. Basically I need to know if its possible, and which unique files/configurations would need changing to achieve it. The end goal: The user would download the H3 image, modify it for their board (eg: copy and paste job on /boot), prior to powering on. Some questions: Is script.bin the only unique configuration across all H3 boards? Aside from any additional linux stuff, like hardware items (eg: + onboard BT/WiFi) Does /usr/lib/linux-u-boot-orangepione_5.17_armhf/*.bin have any effect on the configuration of the board during boot, doesn't script.bin do this already? Could this be done across all sun8i devices? Is there a way we can identify which board we have from within linux? eg: OPi PC. Thinking a service could be created during 1st run to copy the required script.bin to /boot/script.bin automatically. Would require a "compatible" script.bin that could safely be used on all H3 devices. Thanks in advanced. Kind Regards, Dan
  10. Just thought i'd share. SystemD service to automatically logon main screen (tty1) as user root, during boot:
  11. Thanks Tkaiser, Would be interesting to see the results, and, if needed, work on improving those results. I still havn't found a way of physically disabling the onboard BCM wifi/bt. The best we have at the moment is module blacklists, but the chip will still be drawing power i'd assume.
  12. Thanks guys, exactly the info I was after. Yep, so uboot settings can be unique to the device, rather than just the SoC type: So in theory, if I want to use an existing image for a device, I'd need to match the device I want to target, with another device that has the same uboot configuration. Q: Does the .fex (.bin) override the uboot clocks/power regulation etc, rendering the unique uboot settings void? edit: Thanks. I'am all for getting everything little thing out of the device, including power usage . Prime example is the Odroid C1/C2. The HK images have the CPU set to Performance gov by default, we use Ondemand which reduces power consumption when idle by 0.1w~ and heat by 3-5'c. @tkaiser Not sure how I could help at the moment. Do you have some settings that need stability testing for the NanoPi Neo? I can leave it running and report results.
  13. Thanks zador.blood.stained, We don't install cpufreq on DietPi, gov and optional max freq is applied during boot to /sys/devices/system/cpu with script. Q: Is the .fex (script.bin) file responsible for these unique min/max clocks and vcore voltages (if i remember correctly)? Q: On a default compile.sh and configuration.sh, what situations would render this unique to the device, if any? Ah yes, i see. modules available in /etc/modules are unique to the device. It appears compiled modules are the same across all sun8i compiled images. Q: Is it safe to say ARMbian builds the same modules on all devices and kernels?
  14. Hi all, We are now using ARMbian build tools as our 1st choice for all future DietPi SBC images. Currently, we support these devices that use ARMbian at their base: BPI Pro BPI M2+ OPI PC NanoPi Neo I'd like to increase this so we can support more boards with the same ARM SoC (eg: H3). Unfortunately, like most, i do not have access to every SBC out there. As we do further manual optimizations to the ARMbian images, after compile (eg: DietPi-RAMlog, DietPi-RAMdisk, package removals, prep for DietPi scripts etc etc), having the SBC device is essential to creating our image. I'am curious to know if the following is true: Are the Sun8i compiled kernels and modules the same for all devices with that SoC (H3), or are they unique for the device? Is it just a case of matching the ARM SoC (eg: H3), use an existing Sun8i or Sun7i compiled image, then update the /boot/script.bin for the specific device? Example: Compile ARMbian for NanoPi Neo We can now use this image for all H3 devices, as long as we copy the unique script.bin from /boot/bin for each device? Thanks. Another Question: Whats in the packages linux-jessie-root-*? They seem to have alot of dependencies, is python really necessary?: root@DietPi:~# apt-get install linux-jessie-root-orangepipc The following NEW packages will be installed: dh-python file iso-codes libmagic1 libmpdec2 libpython-stdlib libpython2.7-minimal libpython2.7-stdlib libpython3-stdlib libpython3.4-minimal libpython3.4-stdlib libsqlite3-0 linux-jessie-root-orangepipc lsb-release mime-support python python-apt-common python-minimal python2.7 python2.7-minimal python3 python3-apt python3-minimal python3.4 python3.4-minimal 0 upgraded, 25 newly installed, 0 to remove and 0 not upgraded. Need to get 11.7 MB of archives. After this operation, 53.3 MB of additional disk space will be used. Do you want to continue? [Y/n] Thanks guys
  15. Fresh installation of Armbian_5.17_Bananapipro_Debian_jessie_3.4.112.img, built today. Scan now works, but it wont connect. Tried both DHCP (times out) and STATIC, with WiFi creds set in network interfaces: root@bananapipro:~# iwconfig wlan0 wlan0 IEEE 802.11 ESSID:"" Mode:Managed Frequency:2.412 GHz Access Point: Not-Associated Bit Rate:65 Mb/s Tx-Power:32 dBm Retry min limit:7 RTS thr:off Fragment thr:off Power Management:off wlan0 Link encap:Ethernet HWaddr e0:76:d0:03:54:f4 inet addr:192.168.0.188 Bcast:192.168.0.255 Mask:255.255.255.0 inet6 addr: fe80::e276:d0ff:fe03:54f4/64 Scope:Link UP BROADCAST MULTICAST MTU:1500 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:11 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:0 (0.0 TX bytes:910 (910.0 Same issues with setting country code, not saving changes.