Jump to content

Next major upgrade v5.60


Igor

Recommended Posts

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.

Link to comment
Share on other sites

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).

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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. 

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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?

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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 :)

Link to comment
Share on other sites

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 

     

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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

Link to comment
Share on other sites

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

 

Link to comment
Share on other sites

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 ...

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

sunxi-dev changes
https://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

 

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

@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.
Link to comment
Share on other sites

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.

Link to comment
Share on other sites

Guest
This topic is now closed to further replies.
×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines