zador.blood.stained Posted April 10, 2018 Posted April 10, 2018 3 minutes ago, Igor said: HDMI works out of the box which means they are probably deprecated. HDMI may work from u-boot+simplefb, unresolved patches are for the DRM.
jernej Posted April 10, 2018 Posted April 10, 2018 50 minutes ago, zador.blood.stained said: 55 minutes ago, Igor said: HDMI works out of the box which means they are probably deprecated. HDMI may work from u-boot+simplefb, unresolved patches are for the DRM. @Igor zador is correct. Patches can be dropped only when 4.17 is released, so in about 2 months. However, there are many DRM changes in 4.16 so it may be better to backport patches from 4.17, but there are many, including in clocks subsystem. Maybe I can find time to look into that later this week. 1
zador.blood.stained Posted April 10, 2018 Posted April 10, 2018 18 minutes ago, jernej said: Patches can be dropped only when 4.17 is released, so in about 2 months. Not exactly since HDMI audio was not merged yet and I'm not sure what repository and branch should be used for that (I remember seeing I2S patches/fixes on the linux-sunxi ML related to HDMI audio sent by different people).
jernej Posted April 10, 2018 Posted April 10, 2018 36 minutes ago, zador.blood.stained said: Not exactly since HDMI audio was not merged yet audio works with two small DRM patches and few DT changes, so not a big deal, except resolving DT changes.
Igor Posted April 10, 2018 Author Posted April 10, 2018 7 hours ago, JMCC said: But, hey, whatever you see fit guys, you're the ones who make those decisions. I don't want to push anything, I'm perfectly comfortable with keeping all that stuff in some forum thread and maintaining a script from that thread. I would certainly prefer if we could bring this into the build script. But there is no rush.
JMCC Posted April 10, 2018 Posted April 10, 2018 3 hours ago, Igor said: I would certainly prefer if we could bring this into the build script. But there is no rush. So here's what I'm going to do: I will create set of packages and a config script for both Rockchip and XU4, and maintain them in their respective threads. I will try to keep packages not replacing nor conflicting with mainstream. Eventually, you can cherry-pick from there the packages and pieces of code that you want to incorporate into the main build script and the main repo.
jernej Posted April 11, 2018 Posted April 11, 2018 @zador.blood.stained @Igor Do you prefer having each patch in separate file or can I join patches in one file? If we decide to backport, there will be around 30 new patches.
Igor Posted April 11, 2018 Author Posted April 11, 2018 1 minute ago, jernej said: can I join patches in one file Either way, one file is o.k. for me.
zador.blood.stained Posted April 11, 2018 Posted April 11, 2018 I would prefer to not touch 4.16 for now and wait for 4.17, then try to deal with HDMI sound patches.
jernej Posted April 11, 2018 Posted April 11, 2018 Just now, zador.blood.stained said: I would prefer to not touch 4.16 for now and wait for 4.17, then try to deal with HDMI sound patches. You mean using old patches? Why? Check top 3 patches here what needs to be done for HDMI audio. Not much. I2S driver is good enough.
zador.blood.stained Posted April 11, 2018 Posted April 11, 2018 1 minute ago, jernej said: You mean using old patches? Why? I mean using whatever patches are suitable by the time 4.17 is released, not necessarily anything old. 3 minutes ago, jernej said: Check top 3 patches here what needs to be done for HDMI audio. Not much. I2S driver is good enough. So no per-board patches enabling audio like we are enabling HDMI out? And this doesn't have any bad side-effects?
jernej Posted April 11, 2018 Posted April 11, 2018 8 minutes ago, zador.blood.stained said: I mean using whatever patches are suitable by the time 4.17 is released, not necessarily anything old. I'm not sure I'm following you. To be clear, what kind of patches would you like to see for 4.16? Old, new or none? With old or new I mean old out of tree driver and with new new driver which was merged for 4.17. 9 minutes ago, zador.blood.stained said: So no per-board patches enabling audio like we are enabling HDMI out? This is just me being lazy. Old DT HDMI audio changes should be equaly useful for this, since the idea is the same. They just need to be rebased and new boards have to be added. That's why the commit has work "hack" in it.
zador.blood.stained Posted April 11, 2018 Posted April 11, 2018 2 minutes ago, jernej said: To be clear, what kind of patches would you like to see for 4.16? None. As I said, at least I will be skipping 4.16 and will be waiting for 4.17 with main HDMI bits (including DT patches) already merged in.
jernej Posted April 11, 2018 Posted April 11, 2018 9 hours ago, zador.blood.stained said: None. As you wish. There is still simplefb and dev images are not supported anyway and problem will mostly correct itself in 2 months
JMCC Posted April 11, 2018 Posted April 11, 2018 Testing XU4/HC1 Stretch image: Configuring eth0 as static IP with armbian-config works fine, but it creates a duplicate line in "/etc/resolv.conf": nameserver 8.8.8.8 nameserver 8.8.8.8 nameserver 192.168.1.1 Notice that, before doing that, I added "extraargs=net.ifnames=0" to "/boot/armbianEnv.txt", in order to have 'classic' interface names (e.g. "eth0" instead of "enx893ad823f"). Maybe it would be a good idea to include it in all images, in order to maintain consistency between different kernels. Mali devfreq was set to the maximum, which is a waste of power in the headless HC1. It can be changed to dynamic scaling with: echo 'devices/platform/11800000.mali/devfreq/devfreq0/governor = simple_ondemand' >> /etc/sysfs.conf
Igor Posted April 11, 2018 Author Posted April 11, 2018 1 hour ago, JMCC said: Mali devfreq was set to the maximum, which is a waste of power in the headless HC1. It can be changed to dynamic scaling with: Check this script: https://github.com/armbian/build/blob/development/packages/bsp/common/etc/init.d/armhwinfo ... and apply your fix after determining the diff between XU4 and HC1? 1 hour ago, JMCC said: Notice that, before doing that, I added "extraargs=net.ifnames=0" to "/boot/armbianEnv.txt", in order to have 'classic' interface names (e.g. "eth0" instead of "enx893ad823f"). Maybe it would be a good idea to include it in all images, in order to maintain consistency between different kernels. I am not sure we want this but we can add this as a toggle function to armbian-config 1 hour ago, JMCC said: Configuring eth0 as static IP with armbian-config works fine, but it creates a duplicate line in "/etc/resolv.conf": O.K.. Tnx. Tomorrow changes - upstream + all images are rebuild by using upgraded deboostrap ... which is a must to build Ubuntu Bionic.
JMCC Posted April 11, 2018 Posted April 11, 2018 1 hour ago, Igor said: apply your fix after determining the diff between XU4 and HC1 As a matter of fact, I think it can be enabled for both. I haven't noticed any significant performance loss when setting GPU freq scaling for the XU4, because it scales up on demand. And since in most use cases the GPU remains with zero to low usage, the fix can help to keep the SoC a little bit cooler.
Igor Posted April 23, 2018 Author Posted April 23, 2018 Summary of diff between development and master + related from armbian-config. I left out some minor changes: - Network manager is now by default except Espressobin which needs systemd network. Ifupdown can still be overridden if one wanted. - upstream patches for many kernels ... - Ubuntu Bionic target (under expert mode, fully functional testing version) - RFC for firstrun config to set IP or connect to Wireless. Using Network manager method now. - switched NEXT to 4.14.y on Odroid XU4 - kernel packaging support for 4.17.y - RK3399 kernel upstream updates (can't produce bootable image yet) - docker support for RK3328 DEV kernel - sign "sha256sum.sha" instead of "armbian.txt" - add missing dependency libpam-google-authenticator to armbian-config - reworked SSHD management, kernels and nightly/stable switching with armbian-config - added upgrade to desktop from armbian-config (only generic desktop) - added CODA module on imx6 and upstream patches. Requirement for video acceleration but ... haven't got it working under mpv - Olinuxino. Enabled USB within atf, sane RAM speed - icon pack moved to our repository. (Note to myself: remove .deb from build script) - created desktop package per release, architecture independent, could be installed on top of any Debian / Ubuntu base - removed old way of making desktop - moving Odroid away from their mainline sources with a patch - added bionic to the beta repository, soon to main - added Z28PRO to the RK3328 kernel source (tested, working everything but wifi) - meson64 default becomes 4.14.y, next 4.16.y, DEV master - sunxi-dev pinned to 4.16.y and u.boot to v2018.03, most of the patches were adjusted - S56818 is breaking. pinned to last known working kernel 4.14.15 - fixed eMMC install on Rock64 - adding eMMC support for Neo and Neo2 to make images usable for Core / Core2 - added Odroid C1 mainline config (DEV, it should boot but it doesn't) - removing GKSU and rework dependencies Those are areas where we should be focusing. Some are important now, some later. I have done many tests but it's impossible to predict and catch everything. Latest changes will show up in tomorrow's beta repository update and those images which are enabled for the nightly remake. No larger moves until testing and the big merge from my side. I haven't checked: - how changes will affect firstrun and armhwinfo - networking in general. I did only a few tests and notice at least one power management set to "on" ... I think on OPI Prime. - haven't made OMV images 1
Z11ntal33r Posted April 23, 2018 Posted April 23, 2018 Update: I didn't figure out why I suddenly lost internet connection after upgrading packages so I've reinstalled and everything seems to be fine at the moment using 5.41 stable Debian GNU/Linux 9 (stretch) 4.14.34-rockchip. ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ Hi all! I've been using the nightly build for weeks, however, after upgrading today I'm having problems regarding network connection as I can't connect to the internet most of the time. I'm currently on ARMBIAN 5.42.180413 nightly Debian GNU/Linux buster/sid 4.14.35-rockchip, so I'm using a Tinkerboard which have been quite stable lately running headless. I posted an issue some months ago that I had problems with the network adapter going offline after restarting the router etc, yet, I'm not sure if the problem still exists. I can confirm it after solving this issue. Have there been any changes lately which is related to the network adapter or Network Manger? I would be of more help if it wasn't for the exam period I'm currently facing as I'm a student. So I haven't had time to look more into this. The strange thing about the issues are that sometimes I've connection to the internet, but most of the time I don't. I've configured a VPN tunnel for one user which have worked for months so I can't think why that implementation should affect the other users as it is linked to tun0. I've flushed all rules with "sudo iptables -F" just to be sure the firewall rules wasn't the problem. Here is my /etc/network/interfaces file as seen below: Spoiler # armbian-config created source /etc/network/interfaces.d/* auto eth0 allow-hotplug eth0 iface eth0 inet dhcp #no-auto-down eth0 After running "nmcli d" it seems that the eth0 connection is unmanaged. Should the state of eth0 normally say "connected" as it does with tun0? I've tried running "sudo nmcli dev set eth0 managed yes", yet it doesn't change the state of eth0. Spoiler DEVICE TYPE STATE CONNECTION tun0 tun connected tun0 wlan0 wifi disconnected -- dummy0 dummy unmanaged -- eth0 ethernet unmanaged -- ip6tnl0 ip6tnl unmanaged -- sit0 iptunnel unmanaged -- lo loopback unmanaged -- Response running "sudo ip a show eth0" Spoiler 5: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000 link/ether <MyMACAdress> brd ff:ff:ff:ff:ff:ff inet <MyLocalIP>/24 brd 192.168.0.255 scope global eth0 valid_lft forever preferred_lft forever inet6 <MyIP6Adress>/64 scope link valid_lft forever preferred_lft forever "nmcli -p g" response: Spoiler ========================= NetworkManager status ========================= STATE CONNECTIVITY WIFI-HW WIFI WWAN-HW WWAN -------------------------------------------------------------------------------------- connected unknown enabled enabled enabled enabled I've tried to run "sudo ifconfig eth0 up", yet eth0 doesn't show running "nmcli connection" Syslog after rebooting - I think the line "Apr 24 13:35:57 <MyHostName> NetworkManager[567]: <info> [1524576957.0193] settings-connection[0x1f88950,<MyUUID>]: write: failure to update connection: writing settings not supported" might tell us what the problem is. Spoiler Apr 24 13:35:56 <MyHostName> systemd[1]: Starting Network Manager... Apr 24 13:35:56 <MyHostName> NetworkManager[567]: <info> [1524576956.7998] NetworkManager (version 1.10.6) is starting... (for the first time) Apr 24 13:35:56 <MyHostName> NetworkManager[567]: <info> [1524576956.8000] Read config: /etc/NetworkManager/NetworkManager.conf (lib: 10-override-random-mac.conf, no-mac-addr-change.conf, zz-override-wifi-powersave-off.conf) Apr 24 13:35:56 <MyHostName> NetworkManager[567]: <info> [1524576956.8300] manager[0x1f90028]: monitoring kernel firmware directory '/lib/firmware'. Apr 24 13:35:56 <MyHostName> NetworkManager[567]: <info> [1524576956.8302] monitoring ifupdown state file '/run/network/ifstate'. Apr 24 13:35:56 <MyHostName> NetworkManager[567]: <info> [1524576956.9201] hostname: hostname: using hostnamed Apr 24 13:35:56 <MyHostName> NetworkManager[567]: <info> [1524576956.9202] hostname: hostname changed from (none) to "<MyHostName>" Apr 24 13:35:56 <MyHostName> NetworkManager[567]: <info> [1524576956.9210] dns-mgr[0x1f79978]: init: dns=default, rc-manager=resolvconf Apr 24 13:35:56 <MyHostName> NetworkManager[567]: <info> [1524576956.9236] rfkill0: found WiFi radio killswitch (at /sys/devices/platform/ff0d0000.dwmmc/mmc_host/mmc1/mmc1:0001/mmc1:0001:1/ieee80211/phy0/rfkill0) (driver rtl872 Apr 24 13:35:56 <MyHostName> NetworkManager[567]: <info> [1524576956.9263] manager[0x1f90028]: rfkill: WiFi hardware radio set enabled Apr 24 13:35:56 <MyHostName> NetworkManager[567]: <info> [1524576956.9264] manager[0x1f90028]: rfkill: WWAN hardware radio set enabled Apr 24 13:35:56 <MyHostName> systemd[1]: Started Network Manager. Apr 24 13:35:57 <MyHostName> NetworkManager[567]: <info> [1524576957.0100] init! Apr 24 13:35:57 <MyHostName> NetworkManager[567]: <info> [1524576957.0102] interface-parser: parsing file /etc/network/interfaces Apr 24 13:35:57 <MyHostName> NetworkManager[567]: <info> [1524576957.0103] interface-parser: source line includes interfaces file(s) /etc/network/interfaces.d/* Apr 24 13:35:57 <MyHostName> NetworkManager[567]: <warn> [1524576957.0105] interfaces file /etc/network/interfaces.d/* doesn't exist Apr 24 13:35:57 <MyHostName> NetworkManager[567]: <info> [1524576957.0105] interface-parser: finished parsing file /etc/network/interfaces Apr 24 13:35:57 <MyHostName> NetworkManager[567]: <info> [1524576957.0112] guessed connection type (eth0) = 802-3-ethernet Apr 24 13:35:57 <MyHostName> NetworkManager[567]: <info> [1524576957.0114] update_connection_setting_from_if_block: name:eth0, type:802-3-ethernet, id:Ifupdown (eth0), uuid: <MyUUID> Apr 24 13:35:57 <MyHostName> NetworkManager[567]: <info> [1524576957.0119] adding eth0 to connections Apr 24 13:35:57 <MyHostName> NetworkManager[567]: <info> [1524576957.0120] adding iface eth0 to eni_ifaces Apr 24 13:35:57 <MyHostName> NetworkManager[567]: <info> [1524576957.0121] autoconnect Apr 24 13:35:57 <MyHostName> NetworkManager[567]: <info> [1524576957.0121] management mode: unmanaged Apr 24 13:35:57 <MyHostName> NetworkManager[567]: <info> [1524576957.0189] devices added (path: /sys/devices/platform/ff0d0000.dwmmc/mmc_host/mmc1/mmc1:0001/mmc1:0001:1/net/wlan0, iface: wlan0) Apr 24 13:35:57 <MyHostName> NetworkManager[567]: <info> [1524576957.0190] device added (path: /sys/devices/platform/ff0d0000.dwmmc/mmc_host/mmc1/mmc1:0001/mmc1:0001:1/net/wlan0, iface: wlan0): no ifupdown configuration found. Apr 24 13:35:57 <MyHostName> NetworkManager[567]: <info> [1524576957.0191] devices added (path: /sys/devices/platform/ff290000.ethernet/net/eth0, iface: eth0) Apr 24 13:35:57 <MyHostName> NetworkManager[567]: <info> [1524576957.0192] locking wired connection setting Apr 24 13:35:57 <MyHostName> NetworkManager[567]: <info> [1524576957.0193] settings-connection[0x1f88950,<MyUUID>]: write: failure to update connection: writing settings not supported Apr 24 13:35:57 <MyHostName> NetworkManager[567]: <info> [1524576957.0194] devices added (path: /sys/devices/virtual/net/dummy0, iface: dummy0) Apr 24 13:35:57 <MyHostName> NetworkManager[567]: <info> [1524576957.0195] device added (path: /sys/devices/virtual/net/dummy0, iface: dummy0): no ifupdown configuration found. Apr 24 13:35:57 <MyHostName> NetworkManager[567]: <info> [1524576957.0196] devices added (path: /sys/devices/virtual/net/ip6tnl0, iface: ip6tnl0) Apr 24 13:35:57 <MyHostName> NetworkManager[567]: <info> [1524576957.0196] device added (path: /sys/devices/virtual/net/ip6tnl0, iface: ip6tnl0): no ifupdown configuration found. Apr 24 13:35:57 <MyHostName> NetworkManager[567]: <info> [1524576957.0197] devices added (path: /sys/devices/virtual/net/lo, iface: lo) Apr 24 13:35:57 <MyHostName> NetworkManager[567]: <info> [1524576957.0197] device added (path: /sys/devices/virtual/net/lo, iface: lo): no ifupdown configuration found. Apr 24 13:35:57 <MyHostName> NetworkManager[567]: <info> [1524576957.0198] devices added (path: /sys/devices/virtual/net/sit0, iface: sit0) Apr 24 13:35:57 <MyHostName> NetworkManager[567]: <info> [1524576957.0198] device added (path: /sys/devices/virtual/net/sit0, iface: sit0): no ifupdown configuration found. After changing /etc/NetworkManager/NetworkManager.conf to the line below I now at least have a connection running "nmcli d", yet the connection does not last. After some seconds i loose the connection to internet. [ifupdown] managed=true Spoiler DEVICE TYPE STATE CONNECTION eth0 ethernet connected Ifupdown (eth0) tun0 tun connected tun0 wlan0 wifi disconnected -- dummy0 dummy unmanaged -- ip6tnl0 ip6tnl unmanaged -- sit0 iptunnel unmanaged -- lo loopback unmanaged -- Here is the complete list of all the packages I upgraded today before I lost the connection. Spoiler 2018-04-23 14:49:21 upgrade python2.7-dev:armhf 2.7.14-8 2.7.15~rc1-1 2018-04-23 14:49:21 upgrade libpython2.7-dev:armhf 2.7.14-8 2.7.15~rc1-1 2018-04-23 14:49:31 upgrade libpython2.7:armhf 2.7.14-8 2.7.15~rc1-1 2018-04-23 14:49:33 upgrade python2.7:armhf 2.7.14-8 2.7.15~rc1-1 2018-04-23 14:49:40 upgrade libpython2.7-stdlib:armhf 2.7.14-8 2.7.15~rc1-1 2018-04-23 14:49:41 upgrade python2.7-minimal:armhf 2.7.14-8 2.7.15~rc1-1 2018-04-23 14:49:42 upgrade libpython2.7-minimal:armhf 2.7.14-8 2.7.15~rc1-1 2018-04-23 14:49:42 upgrade python-dev:armhf 2.7.14-4 2.7.15~rc1-1 2018-04-23 14:49:43 upgrade python-minimal:armhf 2.7.14-4 2.7.15~rc1-1 2018-04-23 14:49:46 upgrade python:armhf 2.7.14-4 2.7.15~rc1-1 2018-04-23 14:49:48 upgrade libpython-dev:armhf 2.7.14-4 2.7.15~rc1-1 2018-04-23 14:49:49 upgrade libpython-stdlib:armhf 2.7.14-4 2.7.15~rc1-1 2018-04-23 14:49:49 upgrade console-setup-linux:all 1.182 1.184 2018-04-23 14:49:54 upgrade console-setup:all 1.182 1.184 2018-04-23 14:49:54 upgrade keyboard-configuration:all 1.182 1.184 2018-04-23 14:49:55 upgrade libgpg-error0:armhf 1.28-2 1.29-4 2018-04-23 14:49:56 upgrade armbian-config:all 5.43.180418 5.43.180421 2018-04-23 14:49:56 upgrade armbian-firmware:all 5.43.180418 5.43.180421 2018-04-23 14:49:57 upgrade dh-strip-nondeterminism:all 0.040-1 0.041-1 2018-04-23 14:49:58 upgrade libfile-stripnondeterminism-perl:all 0.040-1 0.041-1 2018-04-23 14:49:58 upgrade libapt-pkg-perl:armhf 0.1.33 0.1.34 2018-04-23 14:49:58 upgrade libgirepository-1.0-1:armhf 1.56.0-2 1.56.1-1 2018-04-23 14:49:59 upgrade libhttp-entity-parser-perl:all 0.20-1 0.21-1 2018-04-23 14:49:59 upgrade libmediainfo0v5:armhf 18.03-2 18.03.1-1 2018-04-23 14:50:00 upgrade libwww-robotrules-perl:all 6.01-1 6.02-1 2018-04-23 14:50:02 upgrade linux-dtb-next-rockchip:armhf 5.43.180418 5.43.180421 2018-04-23 14:50:07 upgrade linux-image-next-rockchip:armhf 5.43.180418 5.43.180421 2018-04-23 14:50:11 upgrade linux-u-boot-tinkerboard-next:armhf 5.43.180418 5.43.180421 2018-04-23 14:50:11 upgrade mediainfo:armhf 18.03-1 18.03.1-1 2018-04-23 14:50:12 upgrade python-crypto:armhf 2.6.1-8 2.6.1-9 2018-04-23 14:50:12 upgrade python-gdbm:armhf 2.7.14-3 2.7.15~rc1-1 2018-04-23 14:50:13 upgrade python3-crypto:armhf 2.6.1-8 2.6.1-9 2018-04-23 14:50:14 upgrade sunxi-tools:armhf 1.4.2-2~armbian5.43.180418+1 1.4.2-2~armbian5.43.180421+1 2018-04-23 14:50:14 upgrade unattended-upgrades:all 1.0 1.1 Let me know if you require more information to solve the problem. Regards
AndiH Posted April 25, 2018 Posted April 25, 2018 Hello, I did some testing with the Nightly Build Image for the Odroid HC1 / XU4, and made 2 observations: First a nice one: Seems the idle power consumption with the Nightly Build is even lower than with the current Stable Version (measured with an "ELV Energy Master", and very same Hardware for HC1 / SD Card / HDD in standby): 4.0 - 4.1 Watts with 5.43.180423 nightly, Debian stretch, kernel 4.14.35-odroidxu4 4.3 Watts with 5.41 stable, Debian jessie, 4.9.86-odroidxu4 During the boot process however there seems to be some 12 seconds delay on the Odroid HC1, which does not occur on a XU4. Seems the Kernel is running into some timeout? (Perhaps because the HC1 is headless and has no HDMI?) Here the "dmesg" output on the HC1 (with ARMBIAN 5.43.180423 nightly): [ 2.269968] exynos-gsc 13e00000.video-scaler: Linked as a consumer to 13e80000.sysmmu [ 2.270023] iommu: Adding device 13e00000.video-scaler to group 6 [ 2.271205] exynos-gsc 13e10000.video-scaler: Linked as a consumer to 13e90000.sysmmu [ 2.271263] iommu: Adding device 13e10000.video-scaler to group 7 [ 14.599003] device-mapper: uevent: version 1.0.3 [ 14.599314] device-mapper: ioctl: 4.37.0-ioctl (2017-09-20) initialised: dm-devel@redhat.com And here the same on the XU4 (used exactly same SD Card): [ 2.265929] exynos-gsc 13e00000.video-scaler: Linked as a consumer to 13e80000.sysmmu [ 2.265984] iommu: Adding device 13e00000.video-scaler to group 6 [ 2.267160] exynos-gsc 13e10000.video-scaler: Linked as a consumer to 13e90000.sysmmu [ 2.267219] iommu: Adding device 13e10000.video-scaler to group 7 [ 2.291153] device-mapper: uevent: version 1.0.3 [ 2.291472] device-mapper: ioctl: 4.37.0-ioctl (2017-09-20) initialised: dm-devel@redhat.com Up to this point, the messages in "dmesg" match line-by-line on HC1 and XU4 (of course, the timestamps vary slightly). The Odroid HC1 with the current stable build image (5.41, kernel 4.9.86) doesn't not show such a delay in the boot process. Not a big deal, but I thought to report it here ... 2
TonyMac32 Posted April 25, 2018 Posted April 25, 2018 On 4/23/2018 at 4:35 PM, Z11ntal33r said: Have there been any changes lately which is related to the network adapter or Network Manger? For network adapter, no, I've not done anything to affect that.I can't speak to the management thereof, however.
Igor Posted April 26, 2018 Author Posted April 26, 2018 sunxi-dev changeshttps://github.com/armbian/build/commit/7275cd23167e8d9b6997b35de9eb51a3ce3c5c64 Patches are now somehow better organized (still a lot of to check and adjust) Quick tests with 4.17.0 RC2: Network DVFS USB HDMI Cubietruck yes yes yes yes Opi Prime yes no yes u-boot only Pine H64 yes no yes(2.0) no Opi One no no yes u-boot only LimeA64 no no no u-boot only
Igor Posted April 26, 2018 Author Posted April 26, 2018 16 hours ago, AndiH said: Not a big deal, but I thought to report it here ... Solution: adding this to /boot/boot.ini and by creating or adding to /boot/armbianEnv.txt this: board_name=hc1 It boots strait up.
AndiH Posted April 27, 2018 Posted April 27, 2018 I tried the solution, and can confirm that it works fine, the boot delay is gone :-) Perfect, and thanks a lot!
Igor Posted April 27, 2018 Author Posted April 27, 2018 37 minutes ago, AndiH said: I tried the solution, and can confirm that it works fine, the boot delay is gone :-) Perfect, and thanks a lot! Cool. For future instances, this was pushed to armbian-config and one can select the board he has to get optimized configuration ... which solves such problems.
JMCC Posted May 1, 2018 Posted May 1, 2018 On 23/4/2018 at 8:54 PM, Igor said: Summary of diff between development and master Maybe you can add the fix for the mali4/mali7 conflict in RK3288 Kernel config. Apart from fixing the GPU frequency issue, it made disappear a lot of kernel error messages from syslog. I remember reading in other places that those errors were causing several problems in different RK3288-based boards, though I don't have the links anymore.
JMCC Posted May 1, 2018 Posted May 1, 2018 On 23/4/2018 at 8:54 PM, Igor said: Ubuntu Bionic target (under expert mode, fully functional testing version) I've seen your "experiment" with the Cubie Board. It's interesting . But I guess it does not mean that the change to Bionic is imminent, does it? I'm asking, just to know if it is worth to continue trying to develop the media stuff for Xenial, or I should rather move to Bionic already.
JMCC Posted May 1, 2018 Posted May 1, 2018 @Igor And a couple more suggestions for the next release: Include leafpad and xarchiver as part of the desktop base image. It will be just a few kilobytes more, and right now there are no text editor nor archive manager. If possible, change the OS images archive type from .7z to .xz. Compression ratio will be very similar, and the latter can be flashed directly by Etcher, without the need to decompress it. It will make it easier for new users: as a matter of fact, I would like to make a "How to install Armbian" video for beginners, and if we can skip downloading 7zip, installing it and decompressing the image, it would be a great plus.
zador.blood.stained Posted May 1, 2018 Posted May 1, 2018 34 minutes ago, JMCC said: and the latter can be flashed directly by Etcher, without the need to decompress it. We have multiple files in our archive, does Etcher deal with this correctly without decompressing the archive manually?
JMCC Posted May 1, 2018 Posted May 1, 2018 46 minutes ago, zador.blood.stained said: We have multiple files in our archive, does Etcher deal with this correctly without decompressing the archive manually? Yes, Etcher can flash directly .zip, .gz, .bz2 and .xz without needing to decompress them, but not .7z.
Recommended Posts