- u-boot 2020.04
- kernel 5.7.y
- lot's of patches
- can be rebuild from sources (https://github.com/armbian/build)
Download:
https://www.armbian.com/olimex-teres-a64/
Release history:
https://docs.armbian.com/Release_Changelog/
v1.1
Bump
I've tried suspending the laptop from Xfce, but it hangs while suspending (Teres rev. C). I have no output on the serial line when it happens. Is there any way I can help debug it ?
Other than that, it's a nice work ! It's starting to look good.
For those wondering, from what I've seen there are still some missing parts in v1.1, for instance:
- No Bluetooth
- No sound
- No brightness control
- No battery monitoring
However I've also noticed that the eMMC has much better performance with Armbian than with the Ubuntu from Olimex (45MB/s instead of just 22MB/s according to hdparm). So IMO it's clearly promising :-)
Faster eMMC is interesting! Slow disk access is the main bottleneck in my experience. What kind of benchmark does hdparm do? Is there a way to compare some sort of random access between the old and the new kernel?
hdparm -tT runs a simple sequential read. One with cache enabled (measure more the memory/cpu than the disk) and one without cache.
I can run bonnie++ instead if you want more detailed statistics.
Here are bonnie++ results with Armbian Ubuntu Bionic:
root@teres:/mnt/emmc# bonnie++ -d test -u jflesch:jflesch
Using uid:1000, gid:1000.
Writing a byte at a time...done
Writing intelligently...done
Rewriting...done
Reading a byte at a time...done
Reading intelligently...done
start 'em...done...done...done...done...done...
Create files in sequential order...done.
Stat files in sequential order...done.
Delete files in sequential order...done.
Create files in random order...done.
Stat files in random order...done.
Delete files in random order...done.
Version 1.97 ------Sequential Output------ --Sequential Input- --Random-
Concurrency 1 -Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks--
Machine Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP /sec %CP
teres 4G 141 99 21640 10 16961 9 504 99 39124 9 1661 65
Latency 61414us 4026ms 7753ms 16692us 5852us 6755us
Version 1.97 ------Sequential Create------ --------Random Create--------
teres -Create-- --Read--- -Delete-- -Create-- --Read--- -Delete--
files /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP
16 12299 76 +++++ +++ 8479 41 12721 76 +++++ +++ 7291 36
Latency 78842us 1809us 216ms 115ms 108us 153ms
1.97,1.97,teres,1,1535564920,4G,,141,99,21640,10,16961,9,504,99,39124,9,1661,65,16,,,,,12299,76,+++++,+++,8479,41,12721,76,+++++,+++,7291,36,61414us,4026ms,7753ms,16692us,5852us,6755us,78842us,1809us,216ms,115ms,108us,153ms
Can you run the same on the old kernel? I would do it but I've sent my teres back to olimex.
Here are the results with an Ubuntu Bionic + Olimex kernel 3.10:
root@teres:/# bonnie++ -d test -u jflesch:jflesch
Using uid:1000, gid:1000.
Writing a byte at a time...done
Writing intelligently...done
Rewriting...done
Reading a byte at a time...done
Reading intelligently...done
start 'em...done...done...done...done...done...
Create files in sequential order...done.
Stat files in sequential order...done.
Delete files in sequential order...done.
Create files in random order...done.
Stat files in random order...done.
Delete files in random order...done.
Version 1.97 ------Sequential Output------ --Sequential Input- --Random-
Concurrency 1 -Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks--
Machine Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP /sec %CP
teres 4G 136 97 16336 7 8579 3 814 96 26147 4 1230 38
Latency 68172us 2639ms 6300ms 23869us 176ms 889ms
Version 1.97 ------Sequential Create------ --------Random Create--------
teres -Create-- --Read--- -Delete-- -Create-- --Read--- -Delete--
files /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP
16 8890 47 +++++ +++ 5116 24 10781 56 +++++ +++ 4070 19
Latency 418ms 2697us 347ms 244ms 133us 351ms
1.97,1.97,teres,1,2797863130,4G,,136,97,16336,7,8579,3,814,96,26147,4,1230,38,16,,,,,8890,47,+++++,+++,5116,24,10781,56,+++++,+++,4070,19,68172us,2639ms,6300ms,23869us,176ms,889ms,418ms,2697us,347ms,244ms,133us,351ms
are the filesystems the same?
Both are ext4.
A few numbers which are also not very representative. 4.18.y does not have DVFS yet so CPU stays clocked at 800Mhz.
Armbian: http://ix.io/1n1K
Stock: http://ix.io/1n2D
>No brightness control
At least this should be possible to implement soon, the rest I haven't researched yet.
>I've tried suspending the laptop from Xfce
Suspend works only when the lid is closed.
Bump. New version.
It's looking great ! :)
I just have a minor issue with external displays: When I plug my screen in, it's correctly detected but doesn't turn on. If I reboot the laptop with the screen still plugged in, the screen turns on correctly and everything works fine.
Anyway, it's still far better than what I got with the Olimex distribution: I haven't been able to use any external screens at all with it.
As soon as brightness control is available, Armbian is going straight to the eMMC of my Teres :-)
Quote from: jflesch on November 27, 2018, 12:37:27 AM
As soon as brightness control is available, Armbian is going straight to the eMMC of my Teres :-)
I think for brightness control you have to write to /sys/class/backlight/*/brightness or something like that. To get brightness control via the keyboard probably some configuration for acpid or similar service is needed, but I haven't looked at the latter solution myself yet, so this is just a wild guess.
HTH,
Harald
Brightness control should be operational (via next adjustment/update) via power manager, key binding is AFAIK n/a and suspend/resume solution has to be figured out (after this, beta label goes off). Bluetooth is apparently working, but is not merged yet ... There are ofc still some issues in general + involved people are simply busy to push this further.
It's getting better & better :)
John
Hi, which uboot is armbian using?
Quote from: khumarahn on December 13, 2018, 12:35:22 PM
Hi, which uboot is armbian using?
Mainline 2018.11 with additional patches.
Awesome work. Tried it out today. Had some initial difficulties starting from the SD card (tweaking rootdev in ArmbianEnv.txt seemingly helped), but enjoying better MMC performance now (went from 22Mb/s on stock 3.x kernel to 45Mb/s) and overall it feels good.
One major missing thing for now is that it looks like it doesn't see the sound card so can't make any. While not a showstopper for me, would be interesting to see where's the culprit.
Also, sometimes u-boot just fails out of the blue, but works fine the next time. Besides that, sometimes the login doesn't show up. Going back to the console and back resolves this.
Will try to learn more about Armbian to contribute more.
There might be sound in 5.0, according to http://linux-sunxi.org/Linux_mainlining_effort
Does suspend work in armbian? What about brightness change?
P.S.: I want to understand how the new u-boot and kernel are compiled. I'd like to update the gentoo image to the new kernel.
I tried to boot the latest armbian bionic image from an sd card, but it boots from the eMMC instead.
Is there a manual for dummies on how to debug boot problems? Ideally I would want to compile a new u-boot myself and somehow see that it works, then do a kernel.
About compiling u-boot yourself see: https://wiki.debian.org/InstallingDebianOn/Olimex/Teres-I
(some information might also be in the "going mainline" thread here in the forum.
Sound drivers are available from 4.20. (DTS bits in 5.0). I'm currently working on
the teres-i specific DTS bits - probably will end up in 5.2, maybe 5.1 if I'm lucky.
(Also sound modules aren't compiled for 4.20 in debian yet - I'll send a bug
report asking to enable them, once I have confirmed everything working locally.
suspend/resume works, but doesn't save much power. I suspect the system
doesn't disable lots of subsystems for whatever reason. Didn't look into it at all.
brightness control works for a long time already - but the keys on the keyboard
are not configured to do anything, so you have to set brightness from the
command line.
Quote from: khumarahn on January 29, 2019, 07:12:09 PM
I tried to boot the latest armbian bionic image from an sd card, but it boots from the eMMC instead.
That happened with me once as well (can't recall if it was stretch or bionic), but I either did a hard/soft reboot and it worked properly.
https://wiki.debian.org/InstallingDebianOn/Olimex/Teres-I
There is new Olimex image for the Teres-I and HDMI out now should work fine. Most of the things should also work fine, we tested what we could.
The torrent is here: ftp://staging.olimex.com/Allwinner_Images/A64-Teres/linux/xenial-teres-bspkernel-20190121_144941_EET-1_hdmi_out_v1_5.torrent
Also improved build instructions with docker info. Here: https://github.com/OLIMEX/DIY-LAPTOP/blob/rel3/SOFTWARE/A64-TERES/scripts/Docker.md
I don't have an account in the Debian wiki so if somebody can update those I would appreciate it. Thanks.
I updated the "switch to external screen" entry and updated the torrent link to point to v1.5 on the ftp server. I will soon start testing v1.5 with my Teres and update the page accordingly.
If you place a symlink on the ftp server called something like "teres-xenial-latest", would an external ftp link successfully redirect to the torrent the symlink points to? In that case, no further site updates would be required.
For some reason FTP links don't get treated like regular links in GitHubs markdown. I had to use short url service to get the FTP links with HTTPS prefix to get listed as links. It is well-known issue: https://github.com/gollum/gollum/issues/759
I could install the mainline u-boot and sunxi kernel (5.0-rc2). It boots, I can see in the serial console. But I don't understand how to enable the LCD. What kernel drivers to this?
I did not understand how to boot mainline u-boot and kernel so that the LCD is working. But with armbian's u-boot and kernel it works. Now I have a mostly working installation of gentoo. This feels very nice.
I did not test everything, but right away I see that the clock is always reset to January 1970 on boot, and that the suspend does not work.
Does the clock work for anybody?
Important note: I'm running with the Armbian updates from the nightly build.
Actually, with Armbian, the clock acts a little bit weird on mine: When my laptop is shut down, the clock seems to be frozen. When I restart the laptop, the clock is back at the time it was when I shutted it down. I guess Armbian kernel shuts down everything a little bit too well :)
Anyway NTP takes quickly care of that when the laptop is turned back on so it doesn't really worry me.
What's weirder is suspending: I can suspend the laptop easily, but I need to close and reopen the lid to wake it up (the power button does nothing). I even had once an annoying issue where the laptop would go to sleep when I open the lid and wake back up when I close it (as you can imagine, it was not practical at all ! :) ).
As lambda noted, it does not save much power currently.
One last pain point is U-boot: When the laptop is shut down and I plug it in the electrical outlet, with the U-boot provided by Olimex, it just displays a battery logo and turns back off. But with the U-boot from Armbian, the laptop turns on entirely and boots Linux. That last point is the one that annoys me the most currently.
Anyway all in all, things are starting to look really great with Armbian. I've installed it on the eMMC and I use it daily. I really want to thank all the people that have contributed to it.
Recently, having brightness control has brightened up my days ^^
By the way, just out of curiosity, does someone know if we can expect efficient video playback with Armbian + mpv on the Teres someday ?
Hi all!
As mentioned above, for general instructions about compiling u-boot yourself see: https://wiki.debian.org/InstallingDebianOn/Olimex/Teres-I
Actually, I believe everything required to compile u-boot for the TERES-I is merged upstream except for devicetree+config. Which should be fairly easy to clean up and submit. Anybody going to take that?
(I tried a month ago, but couldn't get it to work immediatly (either broke something when cleaning up or u-boot master of the day was somehow broken) and gave up without looking into it. But should be an easy task for anybody with a serial adapter:
* merge the dts of the patch with the dts from linux
* remove unneeded config items from the patch
* test
* submit to u-boot)
Quote from: khumarahn on February 06, 2019, 04:47:13 PM
I did not understand how to boot mainline u-boot and kernel so that the LCD is working.
IIRC there is a bug in the early 5.0-rc series, which disables the display. If you have LCD working
in u-boot but dark in Linux, this is your problem. If you don't see anything in u-boot either, then
please review the instructions in debian wiki and send your serial boot log.
Quote
I did not test everything, but right away I see that the clock is always reset to January 1970 on boot, and that the suspend does not work.
Does the clock work for anybody?
I haven't noticed any problems with the clock, but maybe olimex firmware and mainline kernel use differnt clock formats and the time gets mixed up every time you switch between kernels?
Suspend not working seems strange though. What's the actual problem you are experiencing?
Quote
What's weirder is suspending: I can suspend the laptop easily, but I need to close and reopen the lid to wake it up (the power button does nothing).
If the laptop is running and you press the power button (quick press and release), does the system shut down?
If not, you are missing the part of the PMIC-driver that handles the power button. (If you press the power button for several seconds, the PMIC will directly shut power down without any driver on the software side involved.)
If you want the u-boot behaviour of the olimex firmware (I don't), then I'd expect that you just have to copy their u-boot script. I don't think you need support in the u-boot binary itself. (But didn't actually try and could easily be wrong.)
Quote
By the way, just out of curiosity, does someone know if we can expect efficient video playback with Armbian + mpv on the Teres someday ?
Yes, the cedrus driver (video decoding) is enabled for A64 in 5.0 - however it will only work with HDMI output at the moment. On LCD we are still stuck with simple-framebuffer driver. I don't know when the drm driver will get merged, but anarsoul from pinebook community seems to be working on it.
HTH,
Harald
Hi Harald,
I used the instructions on the debian wiki to build the u-boot. (I think found them really very useful!) The LCD was dark in u-boot. The only thing I did differently was I used a later branch in
git checkout -b teres origin/pinebook-wip-20180206
I think it was 201811-something. I may try to do it again, if this makes any sense.
Suspend not working is more like jflesch described. I see the LCD go dark, that the power consumption does not change significantly, and then I cannot wake it up. Following jflesch advice, I tried closing and opening the lid, and te machine indeed woke up :-) So let's say that the suspend works in a very strange way.
The clock is always reset to 1 am, 1 Jan 1970. I correct it with ntpd, but it is not saved between the reboots. If I then boot back to Olimex image, the time is somewhere in year 2059 (or so, I do not remember precisely).
Update on RTC: the armbian kernel did not set the time on startup from the hardware source. I turned on the corresponding kernel option, and it works properly now.
Quote from: khumarahn on February 07, 2019, 02:21:21 PM
I used the instructions on the debian wiki to build the u-boot. (I think found them really very useful!) The LCD was dark in u-boot. The only thing I did differently was I used a later branch in
git checkout -b teres origin/pinebook-wip-20180206
I think it was 201811-something. I may try to do it again, if this makes any sense.
Well, if the LCD is dark in u-boot, then u-boot or ATF fail to setup everything correctly.
If you post your serial log, I can have a look.
I think everything from the pinebook-wip branch is merged by now. Somebody tested
Icenowy's patch + mainline u-boot and reported it working via e-mail to me.
I suggest trying again with the documented wip branch or mainline u-boot. I have no
idea about the content of other wip branches ...
Quote
Suspend not working is more like jflesch described. I see the LCD go dark, that the power consumption does not change significantly, and then I cannot wake it up. Following jflesch advice, I tried closing and opening the lid, and te machine indeed woke up :-) So let's say that the suspend works in a very strange way.
Suspend works, but the lid switch is the only wakeup source available. Presumably because of missing power button driver. You can define additional wakeup sources in device tree, but there are few inputs that are sensible. (I think you can't use usb devices, because the TERES doesn't have USB-OTG available on the
exterior.)
HTH,
Harald
Regarding waking up from suspend, would it be possible to make it work with both the lid and power button ? I'm fine with any of them, but I have the feeling it's really confusing for a lot of people when the laptop only wakes up when the lid is being opened.
Looks like I have been wrong on several counts:
1) I completely forgot that backlight support was dropped, when I submitted the teres DT upstream, because the PWM support didn't make it in in time. I had the full DT locally of course (and some distributions picked up the patches anyway, so many people didn't notice) and firmly believed that brightness can be set in sysfs - but probably some of you still can't. (I'll resubmit the patch soon of course.)
2) Seems that enabling the right driver is not enough to get the power button working as a wakeup source. There is also a bug/missfeature in the driver, that prevents this on some PMICs like the AXP803, that teres is using. I'll see what can be done.
3) I kind of implied that the proper drm display driver works with 4.20. Which probably is true, but it isn't enabled for either pinebook or teres in DT. Looks like this is intentional - I guess some issue where proper driver and simple framebuffer (still needed on LCD) can't coexist. (But then maybe the author just didn't have the laptops around to test it there.) Not sure if I'll have time to look into this.
HTH,
Harald
I am very confused by what exactly patches I need to apply to the mainline u-boot and kernel. I ended up using armbian's build system in virtualbox (it did not work in a chroot), where I built deb packages with u-boot and kernel sources. Then I unpack the packages and take what I need. This seems unnecessarily complicated.
I tried to install u-boot and kernel to the eMMC, the same way as it works on an SD card:
u-boot at 8KiB, then ext3 boot partition at 2MiB. I copied the content of the boot partition from the SD card. But it does not boot:
U-Boot SPL 2018.11-rc3-armbian (Feb 05 2019 - 16:24:03 +0000)
DRAM: 2048 MiB
Trying to boot from MMC2
NOTICE: BL3-1: Running on A64/H64 (1689) in SRAM A2 (@0x44000)
NOTICE: Configuring SPC Controller
NOTICE: BL3-1: v1.0(debug):c9f55c0
NOTICE: BL3-1: Built : 16:24:00, Feb 5 2019
NOTICE: DT: sun50i-a64-teres-i
INFO: Configuring AXP PMIC
INFO: PMIC: DRAM voltage: 1.36V
INFO: PMIC: enabled TERES I display power
INFO: PMIC: setup successful
NOTICE: SCPI: dummy stub handler, implementation level: 000000
INFO: BL3-1: Initializing runtime services
INFO: BL3-1: Preparing for EL3 exit to normal world
INFO: BL3-1: Next image address: 0x4a000000, SPSR: 0x3c9
U-Boot 2018.11-rc3-armbian (Feb 05 2019 - 16:24:03 +0000) Allwinner Technology
CPU: Allwinner A64 (SUN50I)
Model: TERES I
DRAM: 2 GiB
MMC: SUNXI SD/MMC: 0, SUNXI SD/MMC: 1
Loading Environment from FAT... Unable to use mmc 1:1... In: serial
Out: vidconsole
Err: vidconsole
Net: No ethernet found.
Card did not respond to voltage select!
Card did not respond to voltage select!
starting USB...
USB0: USB EHCI 1.00
USB1: USB OHCI 1.0
USB2: USB EHCI 1.00
USB3: USB OHCI 1.0
scanning bus 0 for devices... 1 USB Device(s) found
scanning bus 2 for devices... 1 USB Device(s) found
scanning usb for storage devices... 0 Storage Device(s) found
Autoboot in 1 seconds, press <Space> to stop
switch to partitions #0, OK
mmc1(part 0) is current device
Scanning mmc 1:1...
Found U-Boot script /boot.scr
281 bytes read in 3 ms (90.8 KiB/s)
## Executing script at 4fc00000
Card did not respond to voltage select!
Card did not respond to voltage select!
Card did not respond to voltage select!
Card did not respond to voltage select!
Bad Linux ARM64 Image magic!
SCRIPT FAILED: continuing...
Card did not respond to voltage select!
Device 0: device type unknown
... is now current device
No ethernet found.
missing environment variable: pxeuuid
missing environment variable: bootfile
Retrieving file: pxelinux.cfg/00000000
No ethernet found.
missing environment variable: bootfile
Retrieving file: pxelinux.cfg/0000000
No ethernet found.
missing environment variable: bootfile
Retrieving file: pxelinux.cfg/000000
No ethernet found.
missing environment variable: bootfile
Retrieving file: pxelinux.cfg/00000
No ethernet found.
missing environment variable: bootfile
Retrieving file: pxelinux.cfg/0000
No ethernet found.
missing environment variable: bootfile
Retrieving file: pxelinux.cfg/000
No ethernet found.
missing environment variable: bootfile
Retrieving file: pxelinux.cfg/00
No ethernet found.
missing environment variable: bootfile
Retrieving file: pxelinux.cfg/0
No ethernet found.
missing environment variable: bootfile
Retrieving file: pxelinux.cfg/default-arm-sunxi
No ethernet found.
missing environment variable: bootfile
Retrieving file: pxelinux.cfg/default-arm
No ethernet found.
missing environment variable: bootfile
Retrieving file: pxelinux.cfg/default
No ethernet found.
Config file not found
No ethernet found.
No ethernet found.
=>
Am I doing something badly wrong?
You seem to be quite far already, so it can't be badly wrong... :)
Maybe it is something simple. like the kernel image being compressed (some build systems do that by default) but u-boot expecting an uncompressed image? What das 'file <yourkernelimage>' say?
You can always manually enter the commands in your /boot.scr to see where it goes wrong.
About patches:
For the kernel no patches should be strictly necessary. - You will see (in serial console) when you miss something and some important device like backlight fails to come up. However it is very important to have a proper kernel .config, to actually compile all the drivers you need. Usually you can copy the config from any installation and use that as base. Then do "make olddefconfig" as first step in building your own kernel.
For u-boot I'm less sure, because I didn't look into it in details for a long time. But I suspect, that with
a recent u-boot the only patch you need is:
https://github.com/Icenowy/u-boot/commit/960ae79950a2b0a8d2e62bb3dfb5727764512a8b
Maybe you can tell us, where you are being confused?
Thanks! I will try the mainline kernel and u-boot with Icenowy's patch, and will report. I have armbian .config which works, so I will use it as a base.
The kernel image I use is uncompressed one (built with `make Image`). It worked just fine on an sd card, with the same boot.scr. For some reason, it stopped working when copied to eMMC.
`file Image` says: `Image: data`.
But it correctly read '/boot.scr' from the same partition? That's quite strange unless the other device hardcoded in the '/boot.scr' - anway, I guess your only option to find out is to manually step through boot.scr command by command.
Quote from: lambda on February 08, 2019, 06:11:06 PM
But it correctly read '/boot.scr' from the same partition?
Yes, and the boom.scr is generated from a very simple boot.cmd:
setenv bootargs rootwait root=/dev/mmcblk0p2 rootfstype=f2fs debug=on console=tty0 console=ttyS0,115200n8 no_console_suspend
load mmc 0 0x44000000 dtb
load mmc 0 0x41000000 Image
booti 0x41000000 - 0x44000000Identical configuration boots from an sd card and works fine. I will look into the individual commands in boot.cmd soon.
Now, I tried to build the u-boot myself:
git clone https://github.com/ARM-software/arm-trusted-firmware --depth=1
cd arm-trusted-firmware
make PLAT=sun50i_a64 DEBUG=1 -j4 bl31
cd ..
wget https://github.com/Icenowy/u-boot/commit/960ae7.diff
git clone git://git.denx.de/u-boot-sunxi.git --depth=1
cd u-boot-sunxi
git apply ../960ae7.diff
BL31=../arm-trusted-firmware/build/sun50i_a64/debug/bl31.bin make teres_i_defconfig
BL31=../arm-trusted-firmware/build/sun50i_a64/debug/bl31.bin make -j4
cd ..
cp u-boot-sunxi/u-boot-sunxi-with-spl.bin .
It is built on teres itself, so no cross compilation is necessary.
It does not work:
U-Boot SPL 2019.01-ga7cca57 (Feb 09 2019 - 15:42:13 +0000)
DRAM: 2048 MiB
Trying to boot from MMC2
NOTICE: BL31: v2.0(debug):32bcba0
NOTICE: BL31: Built : 15:40:11, Feb 9 2019
NOTICE: BL31: Detected Allwinner A64/H64/R18 SoC (1689)
NOTICE: BL31: Found U-Boot DTB at 0x4084c88, model: TERES I
INFO: ARM GICv2 driver initialized
INFO: Configuring SPC Controller
NOTICE: BL31: PMIC: Detected AXP803 on RSB.
INFO: PMIC: AXP803: dcdc1 voltage: 3.300V
INFO: PMIC: AXP803: dcdc5 voltage: 1.360V
INFO: PMIC: AXP803: dcdc6 voltage: 1.100V
INFO: PMIC: AXP803: dldo1 voltage: 3.300V
INFO: PMIC: AXP803: Enabling DC1SW
INFO: BL31: Platform setup done
INFO: BL31: Initializing runtime services
INFO: BL31: cortex_a53: CPU workaround for 843419 was applied
INFO: BL31: cortex_a53: CPU workaround for 855873 was applied
INFO: BL31: Preparing for EL3 exit to normal world
INFO: Entry point address = 0x4a000000
INFO: SPSR = 0x3c9
U-Boot 2019.01-ga7cca57 (Feb 09 2019 - 15:42:13 +0000) Allwinner Technology
CPU: Allwinner A64 (SUN50I)
Model: TERES I
DRAM: 2 GiB
MMC: mmc@1c0f000: 0
Loading Environment from FAT... In: serial
Out: serial
Err: serial
Net: No ethernet found.
starting USB...
USB0: USB EHCI 1.00
USB1: USB EHCI 1.00
scanning bus 0 for devices... 1 USB Device(s) found
scanning bus 1 for devices... 1 USB Device(s) found
scanning usb for storage devices... 0 Storage Device(s) found
Hit any key to stop autoboot: 2 1 0
MMC Device 1 not found
no mmc device at slot 1
Card did not respond to voltage select!
Device 0: unknown device
No ethernet found.
missing environment variable: pxeuuid
missing environment variable: bootfile
Retrieving file: pxelinux.cfg/00000000
No ethernet found.
missing environment variable: bootfile
Retrieving file: pxelinux.cfg/0000000
No ethernet found.
missing environment variable: bootfile
Retrieving file: pxelinux.cfg/000000
No ethernet found.
missing environment variable: bootfile
Retrieving file: pxelinux.cfg/00000
No ethernet found.
missing environment variable: bootfile
Retrieving file: pxelinux.cfg/0000
No ethernet found.
missing environment variable: bootfile
Retrieving file: pxelinux.cfg/000
No ethernet found.
missing environment variable: bootfile
Retrieving file: pxelinux.cfg/00
No ethernet found.
missing environment variable: bootfile
Retrieving file: pxelinux.cfg/0
No ethernet found.
missing environment variable: bootfile
Retrieving file: pxelinux.cfg/default-arm-sunxi
No ethernet found.
missing environment variable: bootfile
Retrieving file: pxelinux.cfg/default-arm
No ethernet found.
missing environment variable: bootfile
Retrieving file: pxelinux.cfg/default
No ethernet found.
Config file not found
No ethernet found.
No ethernet found.
=>
And there is no display. Probably, there is something I do not understand here.
Quote from: khumarahn on February 09, 2019, 08:21:59 PM
setenv bootargs rootwait root=/dev/mmcblk0p2 rootfstype=f2fs debug=on console=tty0 console=ttyS0,115200n8 no_console_suspend
load mmc 0 0x44000000 dtb
load mmc 0 0x41000000 Image
booti 0x41000000 - 0x44000000
Identical configuration boots from an sd card and works fine. I will look into the individual commands in boot.cmd soon.
Well, probably too identical. "mmc 0" is the sd card. I think you need to replace this with "mmc 1" or "mmc 2" - not sure about the u-boot mmc numbering...
Quote
Now, I tried to build the u-boot myself:
git clone https://github.com/ARM-software/arm-trusted-firmware --depth=1
cd arm-trusted-firmware
make PLAT=sun50i_a64 DEBUG=1 -j4 bl31
I think this is the wrong ATF. You need "atf-allwinner". I think we had a link to the repo in the wiki, but when a proper debian package became available, it was removed, I guess.
Maybe just use the binary from the debian package. I don't remember which version it builds, but it is confirmed working.
(The author / upstream maintainer of atf-allwinner is an arm employee. No idea why this isn't merged into ATF proper. (Maybe size constraints?). The situation is unresolved for long enough, that debian has to ATF packages...
Quote
And there is no display. Probably, there is something I do not understand here.
atf-allwinner sets up some voltages for the eDP bridge.
ATM you have untested ATF + untested u-boot version. I suggest you get rid of one uncertainty (probably ATF) and try to test the other.
HTH,
Harald
Many thanks! I managed to build a u-boot in which the LCD works:
git clone https://salsa.debian.org/debian/atf-allwinner.git --depth=1
cd atf-allwinner
make PLAT=sun50iw1p1 DEBUG=1 -j4 bl31
cd ..
wget https://github.com/Icenowy/u-boot/commit/960ae7.diff
git clone git://git.denx.de/u-boot-sunxi.git --depth=1
cd u-boot-sunxi
git apply ../960ae7.diff
BL31=../atf-allwinner/build/sun50iw1p1/debug/bl31.bin make teres_i_defconfig
BL31=../atf-allwinner/build/sun50iw1p1/debug/bl31.bin make -j4
cd ..
cp u-boot-sunxi/u-boot-sunxi-with-spl.bin .
I was under impression that `mmc 0` is always the boot device... Thanks for the clarification. Now I see that eMMC is `mmc 1`: commands `load mmc 0 0x44000000 dtb` and `load mmc 2 0x44000000 dtb` result in
Card did not respond to voltage select!
but `load mmc 1 0x44000000 dtb` gives no output (probably, works?)
I still cannot boot, but now for a different reason:
=> load mmc 1 0x44000000 dtb
=> load mmc 1 0x41000000 Image
=> booti 0x41000000 - 0x44000000
Bad Linux ARM64 Image magic!
EDIT: u-boot does not see the file boot.scr:
U-Boot 2019.04-rc1-gbe433ef (Feb 09 2019 - 19:42:58 +0000) Allwinner Technology
CPU: Allwinner A64 (SUN50I)
Model: TERES I
DRAM: 2 GiB
MMC: mmc@1c0f000: 0
Loading Environment from FAT... In: serial
Out: vidconsole
Err: vidconsole
Net: No ethernet found.
starting USB...
USB0: USB EHCI 1.00
USB1: USB EHCI 1.00
scanning bus 0 for devices... 1 USB Device(s) found
scanning bus 1 for devices... 1 USB Device(s) found
scanning usb for storage devices... 0 Storage Device(s) found
Hit any key to stop autoboot: 2 1 0
MMC Device 1 not found
no mmc device at slot 1
Card did not respond to voltage select!
Device 0: unknown device
No ethernet found.
missing environment variable: pxeuuid
missing environment variable: bootfile
Retrieving file: pxelinux.cfg/00000000
No ethernet found.
missing environment variable: bootfile
Retrieving file: pxelinux.cfg/0000000
No ethernet found.
missing environment variable: bootfile
Retrieving file: pxelinux.cfg/000000
No ethernet found.
missing environment variable: bootfile
Retrieving file: pxelinux.cfg/00000
No ethernet found.
missing environment variable: bootfile
Retrieving file: pxelinux.cfg/0000
No ethernet found.
missing environment variable: bootfile
Retrieving file: pxelinux.cfg/000
No ethernet found.
missing environment variable: bootfile
Retrieving file: pxelinux.cfg/00
No ethernet found.
missing environment variable: bootfile
Retrieving file: pxelinux.cfg/0
No ethernet found.
missing environment variable: bootfile
Retrieving file: pxelinux.cfg/default-arm-sunxi
No ethernet found.
missing environment variable: bootfile
Retrieving file: pxelinux.cfg/default-arm
No ethernet found.
missing environment variable: bootfile
Retrieving file: pxelinux.cfg/default
No ethernet found.
Config file not found
No ethernet found.
No ethernet found.
=> mmc list
mmc@1c0f000: 0
=> mmc dev 0
Card did not respond to voltage select!
=> mmc info
Card did not respond to voltage select!
(Now I can boot with the u-boot from armbian: I use `load mmc 1` instead of `load mmc 0`. It does not work reliably though: the eMMC is sometimes /dev/mmcblk1 and other times /dev/mmcblk2; in my setup I need a static name, so every about second time linux does not boot.)
Gratulations!
I can't help you with eMMC issues. I'm still running mainline on sd card and olimex on eMMC to have something to cross-check and compare when doing kernel stuff, so you are probably on new territory now.
I guess you could work around the mmc numbering issue by writing a boot script that checks for both. Also maybe somebody works already on it: See this commit for example
http://git.denx.de/?p=u-boot/u-boot-sunxi.git;a=commit;h=708b5da38a19d41e6ccb9bff14f54b5f2d1db43c
Since it seems to be a DT related issue, maybe you can clean up the patch for teres-i support and submit it to u-boot? I think there is a good chance, that cleaning up the patch also fixes the device numbering issues ...
The magic number error is strange. Maybe it is something simple like one u-boot supporting compression and the other not.
HTH,
Harald
Well, I still cannot compile a working u-boot myself; the one of armbian does not count because it is hard to follow what is going on.
I mean, sunxi' branch of u-boot with atf-allwinner (whether I compile if myself or copy is from debian) does not really see the eMMC at all.
Quote from: lambda on February 10, 2019, 12:21:45 AM
The magic number error is strange. Maybe it is something simple like one u-boot supporting compression and the other not.
I think now it is not related to the magic number... The u-boot does not even see the boot.scr, so probably things get wrong somewhere in the very beginning.
OK, I know how to build a working u-boot:
set -e # exit if any command fails
git clone https://salsa.debian.org/debian/atf-allwinner.git --depth=1
cd atf-allwinner
make PLAT=sun50iw1p1 DEBUG=1 -j4 bl31
cp build/sun50iw1p1/debug/bl31.bin ../
cd ..
wget https://github.com/Icenowy/u-boot/commit/960ae7.diff
git clone --single-branch --branch pinebook-wip-20181109 --depth=1 https://github.com/anarsoul/u-boot-pine64.git
cd u-boot-pine64
git apply ../960ae7.diff
BL31=../bl31.bin make teres_i_defconfig
BL31=../bl31.bin make -j4
cp u-boot-sunxi-with-spl.bin ../
cd ..
Now: how to build the mainline u-boot for teres?
Quote
I think now it is not related to the magic number... The u-boot does not even see the boot.scr, so probably things get wrong somewhere in the very beginning.
Hm, then I must have misunderstood something in your previous message. Never mind.
Quote
Now: how to build the mainline u-boot for teres?
Probably not yet. Your results indicate that not everything needed for eMMC is merged yet. (And since anarsoul seems to be actively working on upstreaming his patches, there probably isn't much you can do to speed this up.)
OTOH the teres enable patch seems to work fine and it appears icenowy has stopped working on teres. So bringing this patch to shape and submitting it would help a lot. (And it's no real "building from mainline" so long as this patch is missing.) Also once teres support is in u-boot, people will keep it updated when changing related bits of u-boot, that might break it.
I have a working installation on the eMMC with the u-boot built as above and config that avoids the volatile /dev/mmcblk{1,2} devices:
$ cat /boot/boot.cmd
setenv bootargs rootwait root=PARTUUID=3807bc36-02 rootfstype=f2fs debug=on console=tty0 console=ttyS0,115200n8 no_console_suspend
load mmc 1 0x44000000 dtb
load mmc 1 0x41000000 Image
booti 0x41000000 - 0x44000000
My fstab also uses UUID. It would be good to figure out how to make /dev/mmcblk{1,2} predictable, but it is not a pressing issue.
I'd be happy to cleanup Icenowy's patch. Though I still understand little about what needs to be done. It looks rather clean already, no?
What's the trick to avoid volatile devices? From to code snippet I don't understand what your solution is.
Patch cleanup:
Step 1: Sync the DT in the patch with what we have in the linux kernel now. (Ie use DT from linux kernel, but readd all the nodes, that are in patch but not in linux. - I guess this is mostly the eDP bridge, but check yourself to be sure nothing gets lost.) Have a look at the DT for pinebook to see how it is done. (Also a git log on the pinebook DT might clear up things.)
Step 2: The defconfig probably contains symbols randomly enabled until "it works". Try to disable anything that might be unnecessary. Cross checking with pinebook defconfig will help a lot, but some things are different. (You will now about them once you compare DTs). Also cross check with common sense - maybe there is something that would improve things when enabled. (USB stuff (working keyboard in u-boot anybody?) comes to mind, but I have no idea really).
Step 3: Test. It should work realiably on external sd card. Don't worry if it doesn't work on eMMC, though if you can make it work there (maybe some more patches merged by anarsould in time) even better.
Step 4: Submit it to the right mailinglist/people. I guess scripts/get_mainter.pl is your friend, but I don't know u-boot customs.
TIA,
Harald
Thanks!
Quote from: lambda on February 10, 2019, 08:52:38 PM
What's the trick to avoid volatile devices? From to code snippet I don't understand what your solution is.
That is `root=PARTUUID=3807bc36-02` in kernel command line, in place of `root=/dev/mmcblk1p1`. Apparently, we cannot use UUID there, but PARTUUID works OK. Perhaps, could use partition labels.
Quote from: khumarahn on February 10, 2019, 09:21:53 PM
That is `root=PARTUUID=3807bc36-02` in kernel command line, in place of `root=/dev/mmcblk1p1`. Apparently, we cannot use UUID there, but PARTUUID works OK. Perhaps, could use partition labels.
Hm, that should help the kernel find the rootfs. But how does this help u-boot find the right device to load the kernel from?
Loading kernel works from mmc 1, regardless whether kernel identifies eMMC as /dev/mmcblk1 or /dev/mmcblk2.
Ah, then I completely misunderstood what the issue was. Yes device numbering is not reliable in the kernel. (Hasn't been since 2.6.0 or something.) UUIDs is the way to go. (Also we now use libgpiod instead of /sys/class/gpio for the same reason, etc.)
Update.
Debian Buster and Ubuntu Bionic (preview) with Kernel 5.1.7
https://www.armbian.com/olimex-teres-a64/#kernels-archive
Quote from: igorpec on June 15, 2019, 12:06:05 AM
Update.
Debian Buster and Ubuntu Bionic (preview) with Kernel 5.1.7
https://www.armbian.com/olimex-teres-a64/#kernels-archive
Thanks Igor,
I have tried that and it looks very stable. I am having some problems with the audio but I think I can manage it.
Is there any video acceleration included on the kernel configuration?
Also I tried to build the image on my own but I don't see the 5.1y option on the ./compile.sh script.
Regards,
Lazar
Quote from: d3f on June 17, 2019, 01:49:03 PM
Thanks Igor,
I have tried that and it looks very stable. I am having some problems with the audio but I think I can manage it.
Is there any video acceleration included on the kernel configuration?
No. Coming with 5.2.y, probably also with faster closed source MALI support.
Quote from: d3f on June 17, 2019, 01:49:03 PM
Also I tried to build the image on my own but I don't see the 5.1y option on the ./compile.sh script.
Regards,
Lazar
DEV configuration are hidden by default since we don't want users to build (and ask questions which we are unable to process) those, sometimes very unstable, targets.
Add EXPERT="yes" for unlock.
I tested these days Ubuntu_bionic_dev_desktop.7z 2019-07-07 and experienced crashes.
If it weren't for the crashes i really considered putting it on internal eMMC. Works really nice.
So one thing i did after 1st flash on SD card was to check sound in browser (youtube) so i tried various options for pulseaudio output till it worked. After a reboot it crashed, if i remember well, after gui login.
I flashed again anew and i could use the laptop 2-3 times (no audio tweaking).
This evening i used it again, just reading some news (again the browser) and it crashed in such a way that it actually powered off instantly with a click in the speakers.
Did anybody else experience this? Restarts happened some months ago also when i tried the Armbian image (was maybe the May release?).
Actually i decided to write this post because i found it interesting that this crash caused an immediate poweroff. Writing the post from the "stock" xenial ::)
Possibly a lack of enough good power.
John
Bump. Updated to 5.4.20
(mine seems to have some troubles with a keyboard, so I could not test, but we got reports its working)
Quote from: igorpec on February 19, 2020, 07:28:25 PMBump. Updated to 5.4.20
(mine seems to have some troubles with a keyboard, so I could not test, but we got reports its working)
igorpec so you know, I've just installed this via sd card and it looks wonderful but there is no desktop. xfce has no icons or panels.
EDIT: igor resolved my issue on the armbian forums at https://forum.armbian.com/topic/14042-olimex-teres-latest-bionic/
Major Armbian update:
https://www.armbian.com/newsflash/armbian-20-08-caple/
Thanks for the update, any idea how to get the audio working?
Regards,
Lazar
I managed to get the audio working.
First, asound.state should be updated under /var/lib/alsa. You can get it from here (https://raw.githubusercontent.com/OLIMEX/DIY-LAPTOP/rel3/SOFTWARE/A64-TERES/blobs/asound.state).
Second, on the alsamixer sun50i-a64-card audio card, there is a DAC that needs to be unmuted(if you unmute DAC Reverse, it also works, I don't know the difference).
Third, Line out is the mixer controlling the speakers, and Headphones is the mixer controlling the headphones but by default the audio jack is acting as serial output.
I found that GL9 pin should be 1 in order to get the audio through the jack. I have created bash script to set it up after login because I am not sure how to add it during uboot.
#!/bin/bash
echo 361 > /sys/class/gpio/export
echo "out" > /sys/class/gpio/gpio361/direction
echo 1 > /sys/class/gpio/gpio361/value
echo 361 > /sys/class/gpio/unexport
I am using DWM and following xorg.conf
Section "Device"
Identifier "Lima"
# MatchDriver "sun4i-drm"
Driver "modesetting"
Option "PrimaryGPU" "true"
Option "HWCursor" "false"
Option "SwapbuffersWait" "true"
EndSection
Section "Monitor"
Identifier "Monitor0"
Option "DPMS" "false"
EndSection
Section "ServerFlags"
Option "AutoAddGPU" "off"
Option "BlankTime" "0"
Option "StandbyTime" "0"
Option "SuspendTime" "0"
Option "OffTime" "0"
EndSection
I manage to get it 600 fps on glxgears. Youtube on 480p doesn't drop frames.
Regards,
Lazar
Hi,
i was wondering if someone else experiences this behavior.
After upgrading to version 21.02.1 i have the annoying situation that Teres refuses to start after power on. I believe it is still bootloader phase when it powers off right away.
As of writing,when i tried again, the battery was 54%. It only boots if i plug the power supply. After that it runs fine. I am not using the laptop extensively so it is not a thorough test.
Any pointers? Armbian specifics?
Thanks
Quote from: binutzu on February 25, 2021, 03:41:14 PMAfter upgrading to version 21.02.1 i have the annoying situation that Teres refuses to start after power on. I believe it is still bootloader phase when it powers off right away.
I reinstalled Armbian on SD and using it since weeks.
I can say two things:
- the automatic shuttting /power down could have been related, most probably, to enabling audio via gpio and using the asound.state as explained by Lazar. But i would need to try it out again to be sure.
- if i try to use Armbian after running the Olimex (1.5) image (for things like bluetooth/HDMI), i have problems starting it if only on battery.
Quote from: d3f on November 12, 2020, 08:43:22 PMI am using DWM and following xorg.conf
Do you have the possibility or did you try to use the HDMI output on Armbian? The feature list mentiones it but does not work for me. My display is not detected in Armbian but works fine from Olimex v1.5 image.
Regards,
Florin