Kernel for A64 git

[longsleep]

You still have to worry as Kernel 3.10 is officially end of life since Dec 2015. It still gets the occasional update but its still a very old Kernel tree.

The EOL is actually on October 2017 (longterm maintainence release)

Oh someone took over the 3.10 line recently. Thanks for the hint - i missed that. So its indeed Oct, 2017 now. So then still do not feel safe because of what tkaiser said.

By the way, the upgrade script fails to detect the latest version (3.10.101). It shows that the kernel that I have (3.10.65) is at it's latest version.

I do not see how this could be the case. You know that its not really checking what you run? It is just comparing etags with what it stored before in /var/lib/misc/pine64_update_kernel.status - so remove that file to force it download and apply again.

---

I wanted to check if i could do 720p in U-Boot and show a boot logo and then switch to 1080p with the tool later.

Agreed. This is even better. Resolution switching works fine here but only until X is started. Afterwards it gets messy. So adjusting resolution in uEnv.txt should be the preferred method and people shouldn't be aware that sunxi-disp-tool even exists

Yes - If X runs, the framebuffer cannot be released and recreated or something. So X needs to stop, then change resolution, start X and everything is good. Also wrote it in the README at https://github.com/longsleep/sunxi-disp-...E.md#usage to be sure i can point and say see here - i said so

[tkaiser]

By the way, the upgrade script fails to detect the latest version (3.10.101). It shows that the kernel that I have (3.10.65) is at it's latest version.

I do not see how this could be the case. You know that its not really checking what you run? It is just comparing etags with what it stored before in /var/lib/misc/pine64_update_kernel.status - so remove that file to force it download and apply again.

In case it's a proxy problem adding -H 'Cache-Control: no-cache' might help. And debugging using curl manually with --verbose would be an option too.

[longsleep]

Mhm - the site is TLS encrypted, i do not see how a proxy could cache it.

[Terra854]

By the way, the upgrade script fails to detect the latest version (3.10.101). It shows that the kernel that I have (3.10.65) is at it's latest version.

I do not see how this could be the case. You know that its not really checking what you run? It is just comparing etags with what it stored before in /var/lib/misc/pine64_update_kernel.status - so remove that file to force it download and apply again.

And now I ran into this:

Code:

Checking for update ...
Downloading Linux Kernel ...

curl: (60) SSL certificate problem: unable to get local issuer certificate
More details here: https://curl.haxx.se/docs/sslcerts.html

curl performs SSL certificate verification by default, using a "bundle"
of Certificate Authority (CA) public keys (CA certs). If the default
bundle file isn't adequate, you can specify an alternate file
using the --cacert option.
If this HTTPS server uses a certificate signed by a CA represented in
the bundle, the certificate verification probably failed due to a
problem with the certificate (it might be expired, or the name might
not match the domain name in the URL).
If you'd like to turn off curl's verification of the certificate, use
the -k (or --insecure) option.

By the way, i'm running this on the openSUSE image and this error only appears in openSUSE (other images work fine)

[longsleep]

@Terra854: something is very wrong with your connection and/or image you are running. Could be a simple thing like just wrong system time or a full featured man-in-the-middle attack.

Check like this:

Code:

root@pine64-2gb:~# curl -Iv https://www.stdin.xyz/downloads/people/longsleep/pine64-images/linux/linux-pine64-latest.tar.xz    
*   Trying 5.189.159.217...
* Connected to www.stdin.xyz (5.189.159.217) port 443 (#0)
* found 173 certificates in /etc/ssl/certs/ca-certificates.crt
* found 694 certificates in /etc/ssl/certs
* ALPN, offering http/1.1
* SSL connection using TLS1.2 / ECDHE_RSA_AES_256_GCM_SHA384
*      server certificate verification OK
*      server certificate status verification SKIPPED
*      common name: www.stdin.xyz (matched)
*      server certificate expiration date OK
*      server certificate activation date OK
*      certificate public key: RSA
*      certificate version: #3
*      subject: CN=www.stdin.xyz
*      start date: Sat, 19 Mar 2016 21:13:00 GMT
*      expire date: Fri, 17 Jun 2016 21:13:00 GMT
*      issuer: C=US,O=Let's Encrypt,CN=Let's Encrypt Authority X1
*      compression: NULL
* ALPN, server did not agree to a protocol
> HEAD /downloads/people/longsleep/pine64-images/linux/linux-pine64-latest.tar.xz HTTP/1.1
> Host: www.stdin.xyz
> User-Agent: curl/7.47.0
> Accept: */*
>
< HTTP/1.1 200 OK
HTTP/1.1 200 OK
< Server: nginx
Server: nginx
< Date: Sat, 07 May 2016 14:18:11 GMT
Date: Sat, 07 May 2016 14:18:11 GMT
< Content-Type: application/octet-stream
Content-Type: application/octet-stream
< Content-Length: 46824276
Content-Length: 46824276
< Last-Modified: Sat, 07 May 2016 11:18:16 GMT
Last-Modified: Sat, 07 May 2016 11:18:16 GMT
< Connection: keep-alive
Connection: keep-alive
< ETag: "572dcef8-2ca7b54"
ETag: "572dcef8-2ca7b54"
< Strict-Transport-Security: max-age=15768000
Strict-Transport-Security: max-age=15768000
< Accept-Ranges: bytes
Accept-Ranges: bytes

<
* Connection #0 to host www.stdin.xyz left intact

To see all the details.

---

By the way, i'm running this on the openSUSE image and this error only appears in openSUSE (other images work fine)

Well - that explains it then and is the reason why i recommend only properly created images where the bootstrap scripts are public and i have reviewed (means only my images )

[tkaiser]

By the way, i'm running this on the openSUSE image and this error only appears in openSUSE (other images work fine)

Please think about dropping the whole idea to provide an OpenSUSE image if you aren't able to provide kernel updates! That's the stuff I was talking about here. A non existing OS image is better than a crappy one.

Unless you're willing to provide and maintain(!) a working and non conflicting way to provide kernel/u-boot updates (zypper?) please withdraw your OS image.

[Terra854]

By the way, i'm running this on the openSUSE image and this error only appears in openSUSE (other images work fine)

Please think about dropping the whole idea to provide an OpenSUSE image if you aren't able to provide kernel updates! That's the stuff I was talking about here. A non existing OS image is better than a crappy one.

Unless you're willing to provide and maintain(!) a working and non conflicting way to provide kernel/u-boot updates (zypper?) please withdraw your OS image.

Relax tkaiser, I am willing to maintain the openSUSE image. Besides, I am currently rebuilding the image with the latest released kernel right now. Also, I have implemented a workaround for the problem mentioned above, so providing kernel updates will not be a problem.

[tllim]

Was there some sort of change to the console in this release? I can no long send any input. I can watch over the serial console but nothing back is acknowledged.

Nope - works fine here. Both serial console via UART and also the console on HDMI.

---

optargs=disp.screen0_output_mode=720p60

Do you enable this as default with your next Xenial image? We switched to exactly this display resolution when we started with H3 boards a few months ago and while this led to a couple of overscan reports at least it should help enable display negotiation on more HDMI displays out there.

720p is just so big. I had not planned to enable a low resolution by default fearing "bug" reports like "why" is everything so big on my 5000USD 4K screen. I wanted to check if i could do 720p in U-Boot and show a boot logo and then switch to 1080p with the tool later.

In Android build, this is possible and my Android team just implemented 720P boot up logo screen and 1080p home screen. I assume also can be implemented on Linux.

[longsleep]

Yes i can show a boot logo just fine but the framebuffer driver does not correctly clear/reset when the Kernel takes over ..

---

Also the framebuffer driver does not work properly when U-Boot did initialize HDMI with 720p - so for now everthing stays as it is - U-Boot brings up 1080p and anyone is free to change uEnv.txt to switch to lower resolution. I lack the passion to dig this down - as allways PR welcome

[rhkean]

longsleep,

I honestly don't know if this is a problem, but wanted to bring it to your attention

Code:

        Starting Set console keymap...
[FAILED] Failed to start Set console keymap.
See 'systemctl status console-setup.service' for details.

and, probably unrelated, but shows up in the console log in about the same place

Code:

[   15.519597] [VFE_ERR]Error registering v4l2 subdevice No such device!
[   15.533672] [VFE_ERR]vfe sensor register check error at input_num = 0
[  OK  ] [   15.548861] [VFE_ERR]Error registering v4l2 subdevice No such device!
[   15.563447] [VFE_ERR]vfe sensor register check error at input_num = 1

output from systemctl status:

Code:

[color=#000000]ubuntu@localhost:~$ sudo systemctl status console-setup.service
[sudo] password for ubuntu:
console-setup.service - Set console keymap
  Loaded: loaded (/lib/systemd/system/console-setup.service; static; vendor preset: enabled)
  Active: failed (Result: exit-code) since Sat 2016-05-07 20:24:24 UTC; 50s ago
    Docs: man:loadkeys(1)
 Process: 1706 ExecStart=/usr/bin/loadkeys /etc/console-setup/cached.kmap.gz (code=exited, status=1/FAILURE)
Main PID: 1706 (code=exited, status=1/FAILURE)

May 07 20:24:23 localhost.localdomain systemd[1]: Starting Set console keymap...
May 07 20:24:23 localhost.localdomain loadkeys[1706]: Couldn't get a file descriptor referring to the console
May 07 20:24:24 localhost.localdomain systemd[1]: console-setup.service: Main process exited, code=exited, status=1/FAILURE
May 07 20:24:24 localhost.localdomain systemd[1]: Failed to start Set console keymap.
May 07 20:24:24 localhost.localdomain systemd[1]: console-setup.service: Unit entered failed state.
May 07 20:24:24 localhost.localdomain systemd[1]: console-setup.service: Failed with result 'exit-code'.[/color]

Using new image:  https://www.stdin.xyz/downloads/people/l...7-1.img.xz

Code:

ubuntu@pine64:~$ sudo su -
[sudo] password for ubuntu:
root@pine64:~# bash <(curl -s https://raw.githubusercontent.com/longsleep/build-pine64-image/master/simpleimage/platform-scripts/pine64_update_uboot.sh)
Checking for update ...
You are already on the latest version - no update required.
root@pine64:~# bash <(curl -s https://raw.githubusercontent.com/longsleep/build-pine64-image/master/simpleimage/platform-scripts/pine64_update_kernel.sh)
Checking for update ...
You are already on the latest version - no update required.
root@pine64:~#