jobenvil
-
Posts
60 -
Joined
-
Last visited
Content Type
Forums
Store
Crowdfunding
Applications
Events
Raffles
Community Map
Posts posted by jobenvil
-
-
About the build process, I've noticed that /tmp folder of my workstation is always becoming RO for other groups/users, so after "sudo ./compile.sh" finished, I always need to do a "sudo chmod a+rw /tmp"
Interesting, this could be the reason why my last 4 Virtual Machines (VMware + Ubuntu) died....uhmm?, no, the reason for my problem should be something different. I checked that right now and /tmp is still 777 after building.
-
In the night I downloaded the banana pro image from armbian, the 5.04, then I copied it with Rufus (DD Image + Checking for errors). It took one hour to finish. No errors found (http://pastebin.com/zNgFcYZn). Later I was able to boot and create the user without any problem. Here the dmesg: http://pastebin.com/PLHxHYTg
I see that you added verbosity to the boot process. This will be helpfull in such cases like mine.
Shorted the mmc output from dmesg is following:
root@bananapipro:~# dmesg | grep -i mmc [ 3.193379] reg-fixed-voltage vmmc3: could not find pctldev for node /soc@01c00000/pinctrl@01c20800/vmmc3_pin@0, deferring probe [ 3.682541] sunxi-mmc 1c0f000.mmc: No vqmmc regulator found [ 3.683089] sunxi-mmc 1c0f000.mmc: Got CD GPIO [ 3.717561] sunxi-mmc 1c0f000.mmc: base:0xf08ee000 irq:27 [ 3.733990] sunxi-mmc 1c12000.mmc: No vqmmc regulator found [ 3.754349] mmc0: host does not support reading read-only switch, assuming write-enable [ 3.756779] mmc0: new high speed SDHC card at address b368 [ 3.757604] mmcblk0: mmc0:b368 LEXAR 14.9 GiB [ 3.759042] mmcblk0: p1 [ 3.767456] sunxi-mmc 1c12000.mmc: base:0xf08f2000 irq:28 [ 3.773479] sunxi-mmc 1c12000.mmc: smc 1 err, cmd 8, RTO !! THIS LINE ALWAYS IN RED, ERROR? [ 3.782769] mmc1: queuing unknown CIS tuple 0x80 (2 bytes) [ 3.784267] mmc1: queuing unknown CIS tuple 0x80 (3 bytes) [ 3.785759] mmc1: queuing unknown CIS tuple 0x80 (3 bytes) [ 3.788443] mmc1: queuing unknown CIS tuple 0x80 (7 bytes) [ 3.803508] mmc1: new high speed SDIO card at address 0001 [ 6.319368] systemd[1]: Expecting device dev-mmcblk0p1.device... [ 9.159883] EXT4-fs (mmcblk0p1): mounted filesystem with writeback data mode. Opts: (null)
-
maybe it is another problem. I check the compilation and I had following:
essie.b6eee545ceffad6ec9cb1b12f2a6c61e.tgz: 628MiB [27.7MiB/s] [==========================>] 102% [ o.k. ] Install kernel [ linux-image-next-sunxi_5.04_armhf.deb ] [ o.k. ] Install u-boot [ linux-u-boot-next-sunxi_5.04_armhf.deb ] [ o.k. ] Install headers [ linux-headers-next-sunxi_5.04_armhf.deb ] [ o.k. ] Install firmware [ linux-firmware-image-next-sunxi_5.04_armhf.deb ] [ o.k. ] Install DTB [ linux-dtb-next-sunxi_5.04_armhf.deb ] [ o.k. ] Fixing release custom applications. [ jessie ] Selecting previously unselected package sunxi-tools. (Reading database ... 46115 files and directories currently installed.) Preparing to unpack .../sunxi-tools_1.3-1_armhf.deb ... Unpacking sunxi-tools (1.3-1) ... Setting up sunxi-tools (1.3-1) ... [ o.k. ] Creating boot scripts [ bananapipro ] [ o.k. ] Possible after install. [ customize-image.sh ] [ o.k. ] Writing bootloader [ /dev/loop0 ] [ o.k. ] Shrink image last partition to [ minimum ] losetup: /root/compilation/output/cache/Armbian_5.04_Bananapipro_Debian_jessie_4.4.3.raw: failed to set up loop device: Device or resource busy tune2fs: Bad magic number in super-block while trying to open /dev/loop0 Couldn't find valid filesystem superblock. tune2fs: Bad magic number in super-block while trying to open /dev/loop0 Couldn't find valid filesystem superblock. losetup: /root/compilation/output/cache/Armbian_5.04_Bananapipro_Debian_jessie_4.4.3.raw: failed to set up loop device: Device or resource busy 2: unknown command +: unknown command Re-reading the partition table failed.: Invalid argument [ o.k. ] Create and sign [ Armbian_5.04_Bananapipro_Debian_jessie_4.4.3.zip ] [ o.k. ] Runtime [ 56 min ] root@kali:~/compilation#
Usually I'm not building in this VM (Linux kali 4.3.0-kali1-amd64 #1 SMP Debian 4.3.5-1kali1 (2016-02-11) x86_64 GNU/Linux) but last time so far as I remember It was succesfully for the banana pro compilation but not for the odroidXU4. This time failed the banana pro. I don't know, I have to check the compilation with your ubuntuVM instead with this VM. I have to left right now. I will check later. Thanks once again.
-
here the relevant:
[ 3.774137] sunxi-mmc 1c12000.mmc: smc 1 err, cmd 8, RTO !! [ 3.783427] mmc1: queuing unknown CIS tuple 0x80 (2 bytes) [ 3.784924] mmc1: queuing unknown CIS tuple 0x80 (3 bytes) [ 3.786417] mmc1: queuing unknown CIS tuple 0x80 (3 bytes) [ 3.789101] mmc1: queuing unknown CIS tuple 0x80 (7 bytes) [ 3.804212] mmc1: new high speed SDIO card at address 0001 [ 3.818023] ata1: SATA link down (SStatus 0 SControl 300) [ 3.830828] EXT4-fs (mmcblk0p1): mounted filesystem with ordered data mode. Opts: (null) [ 3.830908] VFS: Mounted root (ext4 filesystem) readonly on device 179:1. [ 3.835046] devtmpfs: mounted
dmesg:
root@bananapipro:~# dmesg | grep ext4 [ 0.000000] Kernel command line: console=tty1 root=/dev/mmcblk0p1 rootwait rootfstype=ext4 cgroup-enable=memory swapaccount=1 sunxi_ve_mem_reserve=0 sunxi_g2d_mem_reserve=0 sunxi_no_mali_mem_reserve sunxi_fb_mem_reserve=16 hdmi.audio=EDID:0 disp.screen0_output_mode=1920x1080p60 panic=10 consoleblank=0 enforcing=0 loglevel=1 [ 3.830908] VFS: Mounted root (ext4 filesystem) readonly on device 179:1.
yes, probably the sd_card. It is lexar High-Speed 16GB class 10. I will see what I can do. Thanks. Probably with first try, was the same RO problem on the background.
-
Care to give an example? We tried to eliminate possible illegal characters but maybe this didn't worked out. And then you're in a reboot trap
Can you please try to adjust line 8 in lib/scripts/check_first_login.sh with
RealUserName="$(echo "${username}" | tr -d -c '[:alpha:]' | tr '[:upper:]' '[:lower:]')"and try it again using the same username? Or better replace the whole file temporarely with the contents from http://pastebin.com/raw/vdUeXndC then try it again and post /var/log/user-creation.log somewhere? Thx
after changing the check_first_login.sh it works somehow. Here the terminal output:
root@192.168.178.30's password: -bash: /var/log/user-creation.log: Read-only file system Thank you for choosing Armbian! Support: www.armbian.com Creating new account. Please provide a username (eg. your forename): achilles Adding user `achilles' ... Adding new group `achilles' (1000) ... groupadd: cannot lock /etc/group; try again later. adduser: `/usr/sbin/groupadd -g 1000 achilles' returned error code 10. Exiting. usermod: user 'achilles' does not exist usermod: user 'achilles' does not exist usermod: user 'achilles' does not exist usermod: user 'achilles' does not exist usermod: user 'achilles' does not exist usermod: user 'achilles' does not exist rm: cannot remove ‘/root/.not_logged_in_yet’: Read-only file system Dear , your account achilles has been created and is sudo enabled. Please use this account for your daily work from now on. root@bananapipro:~#
It looks like that system booted in RO mode:
root@bananapipro:/boot# mount /dev/mmcblk0p1 on / type ext4 (ro,relatime,data=ordered) devtmpfs on /dev type devtmpfs (rw,relatime,size=505360k,nr_inodes=126340,mode=755) sysfs on /sys type sysfs (rw,nosuid,nodev,noexec,relatime) proc on /proc type proc (rw,nosuid,nodev,noexec,relatime) tmpfs on /dev/shm type tmpfs (rw,nosuid,nodev) devpts on /dev/pts type devpts (rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000) tmpfs on /run type tmpfs (rw,nosuid,nodev,mode=755) tmpfs on /run/lock type tmpfs (rw,nosuid,nodev,noexec,relatime,size=5120k) tmpfs on /sys/fs/cgroup type tmpfs (ro,nosuid,nodev,noexec,mode=755) cgroup on /sys/fs/cgroup/systemd type cgroup (rw,nosuid,nodev,noexec,relatime,xattr,release_agent=/lib/systemd/systemd-cgroups-agent,name=systemd) cgroup on /sys/fs/cgroup/cpuset type cgroup (rw,nosuid,nodev,noexec,relatime,cpuset) cgroup on /sys/fs/cgroup/cpu,cpuacct type cgroup (rw,nosuid,nodev,noexec,relatime,cpu,cpuacct) cgroup on /sys/fs/cgroup/blkio type cgroup (rw,nosuid,nodev,noexec,relatime,blkio) cgroup on /sys/fs/cgroup/memory type cgroup (rw,nosuid,nodev,noexec,relatime,memory) cgroup on /sys/fs/cgroup/devices type cgroup (rw,nosuid,nodev,noexec,relatime,devices) cgroup on /sys/fs/cgroup/freezer type cgroup (rw,nosuid,nodev,noexec,relatime,freezer) cgroup on /sys/fs/cgroup/net_cls,net_prio type cgroup (rw,nosuid,nodev,noexec,relatime,net_cls,net_prio) cgroup on /sys/fs/cgroup/perf_event type cgroup (rw,nosuid,nodev,noexec,relatime,perf_event) systemd-1 on /proc/sys/fs/binfmt_misc type autofs (rw,relatime,fd=23,pgrp=1,timeout=300,minproto=5,maxproto=5,direct) mqueue on /dev/mqueue type mqueue (rw,relatime) debugfs on /sys/kernel/debug type debugfs (rw,relatime) fusectl on /sys/fs/fuse/connections type fusectl (rw,relatime) tmpfs on /tmp type tmpfs (rw,nosuid,nodev,relatime,size=262144k) tmpfs on /run/user/0 type tmpfs (rw,nosuid,nodev,relatime,size=102744k,mode=700)
and dmesg:
[ 8.282663] systemd-udevd[160]: starting version 215 [ 8.299699] brcmfmac: brcmf_c_preinit_dcmds: Firmware version = wl0: Apr 22 2013 14:50:00 version 5.90.195.89.6 FWID 01-b30a427d [ 8.315395] brcmfmac: brcmf_cfg80211_reg_notifier: not a ISO3166 code [ 8.964878] sun4i-ss 1c15000.crypto-engine: no reset control found [ 8.966448] sun4i-ss 1c15000.crypto-engine: Die ID 0 [ 9.218466] sun7i-dwmac 1c50000.ethernet: no reset control found [ 9.218493] Ring mode enabled [ 9.218503] No HW DMA feature register supported [ 9.218510] Normal descriptors [ 9.218516] TX Checksum insertion supported [ 9.263874] libphy: stmmac: probed [ 9.263907] eth0: PHY ID 001cc915 at 0 IRQ POLL (stmmac-0:00) active [ 9.263917] eth0: PHY ID 001cc915 at 1 IRQ POLL (stmmac-0:01) [ 9.267169] sun4i-codec 1c22c00.codec: Codec <-> 1c22c00.codec mapping ok [ 14.729415] EXT4-fs (mmcblk0p1): Cannot change data mode on remount [ 15.095964] systemd-journald[161]: Received request to flush runtime journal from PID 1 [ 15.550204] RX IPC Checksum Offload disabled [ 15.550236] No MAC Management Counters available [ 21.537749] sun7i-dwmac 1c50000.ethernet eth0: Link is Up - 1Gbps/Full - flow control rx/tx root@bananapipro:/boot#
because RO filesystem, not possible to create logfile. -
Thanks tkaiser. The username was jobenvil, really not ambiguous ;-) I will check and come to you
-
I have compiled to test new armbian 5.04 in a banana pro (Output: Armbian_5.04_Bananapipro_Debian_jessie_4.4.3.zip). At the first boot it is asking for the new user:
login as: root root@192.168.178.30's password: Thank you for choosing Armbian! Support: www.armbian.com Creating new account. Please provide a username (eg. your forename):
I introduce whatever username and after that the system is booting. There is a loop continuously because after the boot, if I try to login with root, aks again for user but if I login with a created new user doesn't work because the password not was asked before and therefore is not accepting a password. I'm doing something wrong?
I'm connected through SSH; like as usual.
Thanks
-
Hi guys, thanks a lot!, this is what I was looking for. I was reading something similar, but I was not sure.
These is my first concerning: "the boot indication", because without serial cable it is really difficult to observe if it is booting or not.
I saw that it was two patches for enable green leds on some boards and I was asking why not for banana pro. I catch the point. In my case the terrible LED is not disturbing to much because I have placed vertical, near the window.
I agree with your approach and it is understable. I will take the patch and put it inside the user patches.
Here is the summary:
- Now, everytime that I compile a new kernel with Igors tool, I should have the LED lights activated by default on banana pro:
root@kali:~/compilation/userpatches/kernel/sunxi-next# ls -ltr total 4 -rw-r--r-- 1 root root 514 Feb 28 13:39 enable_LEDs_bananapro.patch root@kali:~/compilation/userpatches/kernel/sunxi-next# cat enable_LEDs_bananapro.patch diff --git a/arch/arm/boot/dts/sun7i-a20-bananapro.dts b/arch/arm/boot/dts/sun7i-a20-bananapro.dts index 18fcc87..2f30bfc 100644 --- a/arch/arm/boot/dts/sun7i-a20-bananapro.dts +++ b/arch/arm/boot/dts/sun7i-a20-bananapro.dts @@ -68,11 +68,13 @@ blue { label = "bananapro:blue:usr"; gpios = <&pio 6 2 GPIO_ACTIVE_HIGH>; + linux,default-trigger = "heartbeat"; }; green { label = "bananapro:green:usr"; gpios = <&pio 7 24 GPIO_ACTIVE_HIGH>; + linux,default-trigger = "mmc0"; }; };("compilation" directory is the clone of igors lib repository)
-
Thanks!, but which comand you use to get the diff file? You clone the repo after that make the changes and then apply some diff comand? I supposse this file could be uploaded to my fork of /lib/patch/kernel/sunsi-next and then issue a pull request to Igor? I'm newby in this.
-
@zador.blood.stained I need your help once again. I found this patch for cubietrack in /lib/patch/kernel/sunsi-next:
diff --git a/arch/arm/boot/dts/sun4i-a10-cubieboard.dts b/arch/arm/boot/dts/sun4i-a10-cubieboard.dts index 710e2ef..ffe7625 100644 --- a/arch/arm/boot/dts/sun4i-a10-cubieboard.dts +++ b/arch/arm/boot/dts/sun4i-a10-cubieboard.dts @@ -73,7 +73,7 @@ green { label = "cubieboard:green:usr"; gpios = <&pio 7 20 GPIO_ACTIVE_HIGH>; /* LED2 */ - linux,default-trigger = "heartbeat"; + linux,default-trigger = "mmc0"; }; }; };I want to do the same for Banana Pro. Which is the easy way? Should I fork the torvalds/linux before? Do you have some expample/link how to do it? Thanks in advance
-
Both bananapi and bananapro dts files are present in mainline kernel git repository. And one of kernel maintainers explains here that they don't like setting default triggers in DT because you can change them via sysfs interface (however this means that LEDs won't work in ealry boot until init script or systemd unit sets LED settings).
You can read more about sysfs interface, for example, here.
Oh!, I see, thanks. Very interesting stuff. I will see how to manage it to get them enabled. Afaik there is no willlnes to enable LEDs by default, only some boards that doesn't have dts under /patch have this included by default, because they are "igors property". I enabled them by default for boot and after that in rc.local, like commented by you and tkaiser.
I feel comfortable with these changes:
root@locky ~ # cat /etc/rc.local #!/bin/sh -e # # rc.local # # This script is executed at the end of each multiuser runlevel. # Make sure that the script will "exit 0" on success or any other # value on error. # # In order to enable or disable this script just change the execution # bits. # # By default this script does nothing. ### ### Tunning scaling governor to ondemand from fixed minimal frequency value of 864Mhz: ### echo ondemand >/sys/devices/system/cpu/cpu0/cpufreq/scaling_governor echo 864000 >/sys/devices/system/cpu/cpu0/cpufreq/scaling_min_freq echo 1 > /sys/devices/system/cpu/cpufreq/ondemand/io_is_busy echo 25 > /sys/devices/system/cpu/cpufreq/ondemand/up_threshold echo 10 > /sys/devices/system/cpu/cpufreq/ondemand/sampling_down_factor ### ### Tunning TCP / IP: ### sysctl -w net/core/rmem_max=8738000 sysctl -w net/core/wmem_max=6553600 sysctl -w net/ipv4/tcp_rmem="8192 873800 8738000" sysctl -w net/ipv4/tcp_wmem="4096 655360 6553600" sysctl -w vm/min_free_kbytes=65536 sysctl -w net.ipv4.tcp_window_scaling=1 sysctl -w net.ipv4.tcp_timestamps=1 sysctl -w net.ipv4.tcp_sack=1 sysctl -w net.ipv4.tcp_no_metrics_save=1 ### ### To enable LEDS **bevor** booting we have to convert the dtb to dts and append leds functionality like as follows: ### dtc -I dtb -O dts -o sun7i-a20-bananapro.dts sun7i-a20-bananapro.dtb ### vi sun7i-a20-bananapro.dts ### append lines 1545 and 1551: ### # 1537 leds { # 1538 compatible = "gpio-leds"; # 1539 pinctrl-names = "default"; # 1540 pinctrl-0 = <0x41>; # 1541 # 1542 blue { # 1543 label = "bananapro:blue:usr"; # 1544 gpios = <0x1f 0x6 0x2 0x0>; # 1545 linux,default-trigger = "heartbeat"; # 1546 }; # 1547 # 1548 green { # 1549 label = "bananapro:green:usr"; # 1550 gpios = <0x1f 0x7 0x18 0x0>; # 1551 linux,default-trigger = "mmc0"; # 1552 }; # 1553 }; ### ### convert sun7i-a20-bananapro.dts to sun7i-a20-bananapro.dtb ### dtc -I dts -O dtb -o sun7i-a20-bananapro.dtb sun7i-a20-bananapro.dts ### ### Onboard LEDs enabled **after** booting filesystem: ### echo "cpu0" > /sys/class/leds/bananapro\:blue\:usr/trigger echo "cpu1" > /sys/class/leds/bananapro\:green\:usr/trigger exit 0 -
Thanks Igor. I only see that bananapi.dts and bananapro.dts are equal regarding "green" and in both it is not specified the "default trigger":
root@kali:~/compilation/sources/linux-vanilla/v4.4.3/arch/arm/boot/dts# grep -A4 green sun7i-a20-bananapro.dts green { label = "bananapro:green:usr"; gpios = <&pio 7 24 GPIO_ACTIVE_HIGH>; }; }; root@kali:~/compilation/sources/linux-vanilla/v4.4.3/arch/arm/boot/dts# grep -A4 green sun7i-a20-bananapi.dts green { label = "bananapi:green:usr"; gpios = <&pio 7 24 GPIO_ACTIVE_HIGH>; }; };however going directly to /boot/dtb and using dtc to convert from dtb to dts I can see only a difference:
root@locky /boot/dtb # grep -A4 green sun7i-a20-bananapro.dts green { label = "bananapro:green:usr"; gpios = <0x1f 0x7 0x18 0x0>; }; }; root@locky /boot/dtb # grep -A4 green sun7i-a20-bananapi.dts green { label = "bananapi:green:usr"; gpios = <0x20 0x7 0x18 0x0>; }; };Strange is that in earlier versions the banana.dtb was doing that leds were blinking. Some clues why? Do you take the dts from Hans de Goede? Where you perform the dts changes? in your git? I'm little bit confused.
-
I guess we had some noise in communication. I was doing changes to banana.dtb files in latest release and I request trying using bananapro.dtb which was not touched ... and report was "no change / SATA is not up".
"Changing boot.cmd from default to "sun7i-a20-bananapro.dtb" will do the magic"
If this helps, we only need to fix / update DTB package ... ? If this is 100% I am updating repository with new package.
Edit: I pushed updated kernel (with reverted patch to Banana PRO). It's now kernel defaults ...
Where are you changing the banana*.dtb? I want to take a look, because I want to enable the Banana green Leds depending on the CPU use. -Hope is not this managed by scripts after the hardware ist recogniced-
-
Well, I installed the latest jessie stable (not vanilla) image (with kernel 3.*), and I can confirm that my externally powered 3.5" 4Tb disk is being recognized and works. So, no, it's not a disk or cubie hdd addon package problem. Tomorrow I will try again with the latest vanilla image and the 5.01 patches.
sorry, my earlier answer was for Igor. I don't know why this behaviour. Maybe you can compare the /boot directory for src.bin symlinks to bananapro and dpkg -l to see what you have installed. Can you check if the properly Banana Pro Lemaker appear in dmesg? Only an idea.
-
I guess we had some noise in communication. I was doing changes to banana.dtb files in latest release and I request trying using bananapro.dtb which was not touched ... and report was "no change / SATA is not up".
"Changing boot.cmd from default to "sun7i-a20-bananapro.dtb" will do the magic"
If this helps, we only need to fix / update DTB package ... ? If this is 100% I am updating repository with new package.
Edit: I pushed updated kernel (with reverted patch to Banana PRO). It's now kernel defaults ...
Sorry for the delay, but I wanted to be sure. I think we need both, u-boot 5.01 and fix dtb package. With u-boot 5.00 and dtb not linked to bananapro it still doesn't work. I tried this right now and after that always shutdown -h now.
Working SATA now with 5.01:
[ 3.467792] ahci-sunxi 1c18000.sata: controller can't do PMP, turning off CAP_PMP [ 3.467849] ahci-sunxi 1c18000.sata: SSS flag set, parallel bus scan disabled [ 3.467881] ahci-sunxi 1c18000.sata: AHCI 0001.0100 32 slots 1 ports 3 Gbps 0x1 impl platform mode [ 3.467897] ahci-sunxi 1c18000.sata: flags: ncq sntf stag pm led clo only pio slum part ccc [ 3.469389] ata1: SATA max UDMA/133 mmio [mem 0x01c18000-0x01c18fff] port 0x100 irq 32 [ 3.817752] ata1: SATA link up 3.0 Gbps (SStatus 123 SControl 300) [ 3.818828] ata1.00: ATA-8: ST750LX003-1AC154, SM12, max UDMA/133 [ 3.818841] ata1.00: 1465149168 sectors, multi 0: LBA48 NCQ (depth 31/32) [ 3.820802] ata1.00: configured for UDMA/133 [ 3.821571] scsi 0:0:0:0: Direct-Access ATA ST750LX003-1AC15 SM12 PQ: 0 ANSI: 5
Downgraded:
root@bananapi:~# apt-get install linux-u-boot-bananapi-next=5.00 Reading package lists... Done Building dependency tree Reading state information... Done The following packages will be DOWNGRADED: linux-u-boot-bananapi-next 0 upgraded, 0 newly installed, 1 downgraded, 0 to remove and 0 not upgraded. Need to get 0 B/175 kB of archives. After this operation, 0 B of additional disk space will be used. Do you want to continue [Y/n]? Y dpkg: warning: downgrading linux-u-boot-bananapi-next from 5.01 to 5.00 (Reading database ... 44341 files and directories currently installed.) Preparing to replace linux-u-boot-bananapi-next 5.01 (using .../linux-u-boot-bananapi-next_5.00_armhf.deb) ... Unpacking replacement linux-u-boot-bananapi-next ... Setting up linux-u-boot-bananapi-next (5.00) ...
root@bananapi:~# shutdown -h now
Using username "root". root@192.168.178.30's password: ____ | __ ) __ _ _ __ __ _ _ __ __ _ | _ \ / _` | '_ \ / _` | '_ \ / _` | | |_) | (_| | | | | (_| | | | | (_| | |____/ \__,_|_| |_|\__,_|_| |_|\__,_| Welcome to ARMBIAN Debian GNU/Linux 7 (wheezy) 4.4.1-sunxi System load: 0.80 Up time: 40 sec Memory usage: 3 % of 1003Mb IP: 192.168.178.30 CPU temp: 35°C Usage of /: 29% of 3.6G [ 1 updates to install: apt-get upgrade ] Last login: Wed Feb 17 18:26:37 2016 from achilles.fritz.box
then
root@bananapi:~# dmesg|grep -i ata [ 0.000000] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache [ 0.000000] Memory policy: Data cache writealloc [ 0.000000] Memory: 1010824K/1046952K available (6822K kernel code, 256K rwdata, 1760K rodata, 328K init, 280K bss, 19744K reserved, 16384K cma-reserved, 244136K highmem) [ 0.000000] .data : 0xc08bc000 - 0xc08fc1a0 ( 257 kB) [ 3.194627] libata version 3.00 loaded. [ 3.437420] ahci-sunxi 1c18000.sata: PHY power up failed. [ 3.437488] ahci-sunxi: probe of 1c18000.sata failed with error -5 [ 3.723642] EXT4-fs (mmcblk0p1): mounted filesystem with writeback data mode. Opts: (null) [ 7.623411] EXT4-fs (mmcblk0p1): re-mounted. Opts: data=writeback,commit=600,errors=remount-ro
SATA is missing.
root@bananapi:~# cd /boot root@bananapi:/boot# ls -ltr total 6592 -rwxr-xr-x 1 root root 6944 Jun 10 2015 boot.bmp -rwxr-xr-x 1 root root 4826200 Feb 11 21:58 vmlinuz-4.4.1-sunxi -rw-r--r-- 1 root root 1745862 Feb 11 21:58 System.map-4.4.1-sunxi drwxr-xr-x 2 root root 4096 Feb 11 21:58 dtb.old -rw-r--r-- 1 root root 132628 Feb 11 21:58 config-4.4.1-sunxi -rwxr-xr-x 1 root root 1476 Feb 17 14:27 boot.cmd.backup drwxr-xr-x 2 root root 4096 Feb 17 14:29 dtb drwxr-xr-x 2 root root 4096 Feb 17 14:31 bin lrwxrwxrwx 1 root root 19 Feb 17 14:31 zImage -> vmlinuz-4.4.1-sunxi -rw-r--r-- 1 root root 1770 Feb 17 15:06 boot.src.bananapi -rwxr-xr-x 1 root root 1736 Feb 17 18:18 boot.cmd -rw-r--r-- 1 root root 1808 Feb 17 18:18 boot.scr lrwxrwxrwx 1 root root 25 Feb 17 18:19 script.bin -> /boot/bin/bananapipro.bin root@bananapi:/boot# grep -i banana boot.cmd ext4load mmc 0 0x49000000 /boot/dtb/sun7i-a20-bananapro.dtb || fatload mmc 0 0x49000000 /dtb/sun7i-a20-bananapro.dtb
root@bananapi:/boot# dpkg -l | grep next ii linux-dtb-next-sunxi 5.00 armhf Linux DTB, version 4.4.1-sunxi ii linux-firmware-image-next-sunxi 5.00 armhf Linux kernel firmware, version 4.4.1-sunxi ii linux-headers-next-sunxi 5.00 armhf Linux kernel headers for 4.4.1-sunxi on armhf ii linux-image-next-sunxi 5.00 armhf Linux kernel, version 4.4.1-sunxi ii linux-u-boot-bananapi-next 5.00 armhf Uboot loader 2016.01 ii linux-wheezy-root-next-bananapi 5.00 armhf Root file system tweaks for bananapi
-
I think so, but take care that the SATA errors on dmesg output depending on 5.00 or 5.01 -and same default bananapi.dtb- are not equal.
with 5.00:
[ 3.448110] ahci-sunxi 1c18000.sata: PHY power up failed. [ 3.448184] ahci-sunxi: probe of 1c18000.sata failed with error -5
with 5.01:
[ 3.827349] ata1: SATA link up 3.0 Gbps (SStatus 123 SControl 300) [ 8.827195] ata1.00: qc timeout (cmd 0xec) [ 8.827214] ata1.00: failed to IDENTIFY (I/O error, err_mask=0x4) [ 9.177171] ata1: SATA link down (SStatus 0 SControl 300)
-
The only thing i did in addition was changing "ext4load mmc 0 0x49000000 /boot/dtb/sun7i-a20-bananapro.dtb in /boot/boot.cmd", but i think that should not make the difference.
I can confirm this weird behaviour: "changing "ext4load mmc 0 0x49000000 /boot/dtb/sun7i-a20-bananapro.dtb in /boot/boot.cmd" and it made the difference between recognice the SATA or not at the boot time (and after that as well).
The prebuilt image (with u-boot 5.0.0 & 5.0.1) doesn't work with SATA until we linked the dtb files with the model "bananapro" and not with bananapi default, which is automatically triggered after every upgrade.
Changing boot.cmd from default to "sun7i-a20-bananapro.dtb" will do the magic:
ext4load mmc 0 0x49000000 /boot/dtb/sun7i-a20-bananapro.dtb || fatload mmc 0 0x49000000 /dtb/sun7i-a20-bananapro.dtb
having this packages installled:
root@bananapi:/boot# dpkg -l|grep next ii linux-dtb-next-sunxi 5.00 armhf Linux DTB, version 4.4.1-sunxi ii linux-firmware-image-next-sunxi 5.00 armhf Linux kernel firmware, version 4.4.1-sunxi ii linux-headers-next-sunxi 5.00 armhf Linux kernel headers for 4.4.1-sunxi on armhf ii linux-image-next-sunxi 5.00 armhf Linux kernel, version 4.4.1-sunxi ii linux-u-boot-bananapi-next 5.01 armhf Uboot loader 2016.01 ii linux-wheezy-root-next-bananapi 5.00 armhf Root file system tweaks for bananapi
This starts to be litte tricky; since my first ARMBIAN version (4.0.5 ~ Juli 2015) for Banana Pro I suffered with every ARMBIAN upgrade this collateral damage because banana pi and pro are not properly recogniced.
Why this? It is not possible to trigger the scripts to manage both separatedly?
I tested:
1) SATA error manifests with this error on u-boot 5.0.1:
3.477254] ahci-sunxi 1c18000.sata: controller can't do PMP, turning off CAP_PMP [ 3.477317] ahci-sunxi 1c18000.sata: SSS flag set, parallel bus scan disabled [ 3.477351] ahci-sunxi 1c18000.sata: AHCI 0001.0100 32 slots 1 ports 3 Gbps 0x1 impl platform mode [ 3.477367] ahci-sunxi 1c18000.sata: flags: ncq sntf stag pm led clo only pio slum part ccc [ 3.478886] ata1: SATA max UDMA/133 mmio [mem 0x01c18000-0x01c18fff] port 0x100 irq 33 [ 3.827349] ata1: SATA link up 3.0 Gbps (SStatus 123 SControl 300) [ 8.827195] ata1.00: qc timeout (cmd 0xec) [ 8.827214] ata1.00: failed to IDENTIFY (I/O error, err_mask=0x4) [ 9.177171] ata1: SATA link down (SStatus 0 SControl 300)
2) SATA error manifests with this error on u-boot 5.0.0 (downgrade with apt-get install linux-u-boot-bananapi-next=5.00)
root@bananapi:~# dmesg| grep ata [ 0.000000] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache [ 0.000000] Memory policy: Data cache writealloc [ 0.000000] Memory: 1010820K/1046952K available (6822K kernel code, 256K rwdata, 1760K rodata, 328K init, 280K bss, 19748K reserved, 16384K cma-reserved, 244136K highmem) [ 0.000000] .data : 0xc08bc000 - 0xc08fc1a0 ( 257 kB) [ 3.205237] libata version 3.00 loaded. [ 3.448110] ahci-sunxi 1c18000.sata: PHY power up failed. [ 3.448184] ahci-sunxi: probe of 1c18000.sata failed with error -5
In this situation it means that the 5.0.1 U-boot version doesn't work properly, or I'm doing something wrong?. I tested this starting with ARMBIAN 4.0.5 on SD and consecutively upgrading.
Fazit: U-boot 5.0 failed like 5.0.1 until the change of the bananapro dtb file, this made the trick.
Another different issue: I realized that the banana led lighting only works with bananapi.dtb and not with bananapro.dtb. It is possible to do the same for bananapro.dtb out of the box? I really like that led is lighting according to CPU/IOs -or whatever-.
Tests were performed with a 2,5" HDD SEAGATE Momentus ST750LX003 750GB which was recogniced before without issues.
-
I'm using Debian testing too with commented Armbian repository, but it should work with jessie-specific config since both jessie and stretch are systemd-based.
➜ ~ % cat /etc/apt/sources.list.d/armbian.list deb http://apt.armbian.com jessie main
Downgrading kernel, u-boot and other packages should be possible by manually downloading and installing packages from apt repository, or by specifying package version for apt-get manually (apt-get install <package>=<version>)
Youcan check available versions using i.e.
apt-cache madison linux-image-next-sunxi
linux-image-next-sunxi | 5.00 | http://apt.armbian.com jessie/main armhf Packages linux-image-next-sunxi | 4.81 | http://apt.armbian.com jessie/main armhf Packages linux-image-next-sunxi | 4.70 | http://apt.armbian.com jessie/main armhf Packages linux-image-next-sunxi | 4.6 | http://apt.armbian.com jessie/main armhf Packages linux-image-next-sunxi | 4.5 | http://apt.armbian.com jessie/main armhf Packages linux-image-next-sunxi | 4.4 | http://apt.armbian.com jessie/main armhf Packages linux-image-next-sunxi | 4.3 | http://apt.armbian.com jessie/main armhf Packages linux-image-next-sunxi | 4.2 | http://apt.armbian.com jessie/main armhf Packages
BTW, if you are experiencing SATA issues on Banana Pro, please check this topic, it might be u-boot related and may be already fixed in new u-boot release.
thanks!!! very interesting both tips and where the armbian repository is placed on.
-
"Upgrade script" was created mainly for older distributions that didn't have Armbian apt repository set up. For more or less fresh versions upgrade should be done with apt (apt-get update && apt-get upgrade).
Sometimes though you may need to additionally tweak something manually here or there (like modifying u-boot script or installing fake-hwclock package).
For installing self-compiled stuff - kernel and DTB (if kernel requires it) should be installed always in pair; updating headers and firmware may be necessary if you use them (i.e. self-compiled drivers of Wi-Fi modules that require firmware). Updating u-boot is generally not needed unless there were device-specific fixes made for it.
DTB deb package may give error with FAT /boot partition (i.e. with rootfs on NAND or devices with older u-boot), deleting old package and removing files in /boot manually should solve this issue.
I was sure, that you will answer, thank you. I try to revert to old kernels to get the banana pro working again (but not right now).
Yes, I realized about the armbian repository using the usual apt-get upgrade in new armbian builts. The point is that I'm using the Debian testing packages and therefore I have #commented the armbian repository list, therefore not getting these automatically. Probably there is another smarter solution to cohexist both of them, but I'm not aware and because it is so easy to compile own kernels now, due to your efforts on compile script, I don't care anymore that I have #commented armbian repository. However will be nice if some aditional infos could be pushed on the docus, focushing on people that is installing kernel on top of igors prebuilt images and how to revert to old kernels. I see that this was commented sometimes here or there in the Forum.
Yes, indeed, you are totally right mentioning the /boot problem.
-
After Upgrade "armbian ...| bash" my system banana pro was broken as well. rootfs are in SATA disk.
My questions:
Which is the official installation procedure of the *.deb packages (kernel, boot, firmware, dtbs, etc) that were compiled with the ./compile.sh script? I could not find anything.
And which one *deb files are mandatory in top of the prebuilt release? For example, when I compiled the 3.10.96 for odroidxu4 on the top of a prebuilt 3.10.94 I didn't know certanly which of them were necessary and which not. For example the *.deb of DTBs was giving error because the original file could not be copied, but it looks like that it works nice now.
Thanks in advance
-
I appreciate your answer. What I built until now, doesn't work. I Followed basically the same link for Kernel 4.2 (tobetter) but without succes. I was using gparted to mov ext4 and then expand fat partition because I got a big 26MB uInitrd file. After that fix it with fsck. Unfortunatelly I don't have UART and its like a feeling everytime that start the boot process. At least, due to the tty1 I can see where it stops the boot. I'm also confused with why Igors armbian doesn't use the uInitrd and adress inside the boot.ini. Igor is mountig on /boot the /dev/mmcblk0p1 and here I'm also little bit confused following the compiling guide from ummilddeb. Probably having the Igors base image from 3.10.94 is not working, because some scripts are mounted or depending in this /boot, which in ummilddeb is placed on /media/boot and respecting the /boot of ext4. BTW, I have to read a lot your given inputs.
- So, you use default config odroidxu4_defconfig ? or you select other choices inside?
- Which boot.ini do you use for 4.*? needs only zImage, dtb file and uInitrd?
Thank you in advance
PS: Igor, if we need to open a new topic, feel free to advice.
-
@wildcats_paris
Have you built a "good" 4.2.* kernel? I had many issues with rootfs on USB3 (Igors armbian 3.10.94) using jMICROn bridge adapter (maybe I should retire it and buy a new one controller). I could not fix it because I didn't know if the problem was at micron controller side (I runned update firmware) or at kernel side https://github.com/hardkernel/linux/issues/120#issuecomment-180874515.
BTW is a good feeling to observe 8 CPUS working together
-
thanks for the explanation! yes, I was thinking about if the keyword "motd" was producing some unexpected behaviour in the search process...
I extended your file:
root@locky ~ # vi /etc/init.d/armhwinfo
adding one line more (#119) in the mentioned "armhwinfo" file, the script chooses the "banana pro" and the motd feeling looks like more accurate.
101 102 if [[ $KERNELID != "3.4" ]]; then 103 MACHINE=$(cat /proc/device-tree/model) 104 fi 105 106 if [[ $MACHINE == *LIME2 ]]; then ID="Lime 2"; fi 107 if [[ $MACHINE == *LIME ]]; then ID="Lime"; fi 108 if [[ $MACHINE == *Micro ]]; then ID="Micro"; fi 109 if [[ $MACHINE == *Banana* ]]; then ID="Banana"; fi 110 if [[ $MACHINE == *Udoo* ]]; then ID="udoo"; fi 111 if [[ $MACHINE == *Lamobo* ]]; then ID="Lamobo R1"; fi 112 if [[ $MACHINE == *Orange* ]]; then ID="Orange"; fi 113 if [[ $MACHINE == *Neo* ]]; then ID="Udoo Neo"; fi 114 if [[ $MACHINE == *Cubietruck* ]]; then ID="Cubietruck"; fi 115 if [[ $MACHINE == *Cubieboard* ]]; then ID="Cubieboard"; fi 116 117 if [[ $MACHINE == *M2* ]]; then ID=$ID" M2"; fi 118 # added by me 24.10.2015 119 if [[ $MACHINE == *Pro* ]]; then ID="Banana Pro"; fiand changing the parameters of toilet:
123 echo $ID >> /var/run/machine.id 124 125 echo "" > /var/run/motd.dynamic 126 # original below 127 #toilet -f standard -F metal "$ID" >> /var/run/motd.dynamic 128 # modified by me 24.10.2015 129 figlet-toilet -F border -F gay -f standard "$ID" >> /var/run/motd.dynamic 130 #echo "$DISTROID - $DISTROCODE - $KERNELID - $KERNELDATE" >> /var/run/motd.dynamic 131 echo "" >> /var/run/motd.dynamicto get something like this:
-
Hi, thanks, somehow the search in the forum for "motd" doesn't work. I got a 404 error, but searching for other keywords wrked well. Many thanks,,, Im reading now...
Here it is the key:
root@locky ~ # toilet -f standard -F metal Banana Pro >> /var/run/motd.dynamic root@locky ~ # cat /var/run/motd.dynamic Linux locky 4.2.3-sunxi #2 SMP Sun Oct 11 14:12:18 CEST 2015 armv7l ____ ____ | __ ) __ _ _ __ __ _ _ __ __ _ | _ \ _ __ ___ | _ \ / _` | '_ \ / _` | '_ \ / _` | | |_) | '__/ _ \ | |_) | (_| | | | | (_| | | | | (_| | | __/| | | (_) | |____/ \__,_|_| |_|\__,_|_| |_|\__,_| |_| |_| \___/ root@locky ~ #
beatifull thing this toilet, but it sound like toilette...
Banana PRO: Testers wanted! SATA drive not working on some boards.
in Allwinner sunxi
Posted
Nein, wir haben Dich/Euch zu danken!