• Content Count

  • Joined

  • Last visited

1 Follower

About divis1969

  • Rank
    Advanced Member

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. Well, I did not find the exact reason why there was no kernel logs. Most likely I've removed SD card from card reader without proper ejecting. I've spent some time creating a suitable development environment (I've found Armbian is not userdeveloper-friendy) and finally was able to figure out the reason of the boot failure. That is a patch/kernel/sunxi-current/0111-mfd-axp20x-Add-AC-power-supply-cell-for-AXP813.patch which adds a duplicate entry axp20x-ac-power-supply into a cell list of axp20x MFD device. I've renamed this patch to *.disabled, rebuilt the kernel and it has booted successfully from SD card (did not yet try to install bootloader and system to emmc - I've removed previous one in assumption it affects the boot, actually not). As for the dev env: what is the best practice to modify and re-build a kernel in Armbian build system? The simplest way seems to create a patch and place it somewhere under patch/kernel. That is because build system cleans the kernel unconditionally.
  2. Well, I've built the Armbian and tried to run it from SD. Unfortunately, it enters boot loop. I've attached the log from console. I'm not familiar with u-boot, it looks like u-boot is loaded from SD, but all the boot scripts were taken from mmc (I did not remove my previous OS from it). Note that I've set verbosity to 7 and console to serial in SD's /boot/armbianEnv.txt and the same should still persist in the mmc's /boot/armbianEnv.txt, but there is no logs from kernel boot. Weird... Can I prevent u-boot to read boot scripts from emmc? minicom-5.3.9.log
  3. I'm not sure. Perhaps I had enabled this manually, or I had started from dev build a long time ago... Sudo apt upgrade had upgraded the kernel as well. First time I had just recovered from this by booting from sd card and modifying links at emmc /boot for kernel and dtb and copying initram from sd. This time I've first collected this log. Well, hopefully I will have some time to debug it.
  4. Hi, I had Armbian based on kernel 4.19 installed on emmc. It was running pretty good for a long time but recently it was automatically upgraded to kernel 5.3.9 and started to restart while booting. I had collected a log (see attachment), It looks like it was unable to find root partition and this is most likely caused by issue with axp20x_device_probe. Is this a known issue? Is there any remedy? minicom.log
  5. Check 'cat /proc/device-tree/model' or other nodes under /proc/device-tree. This is the loaded device tree seen by kernel.
  6. And what is the final configuration: versions of u-boot, kernel and dtb (was linux-dtb-next-sunxi updated in any of the test above)?
  7. Well, that's all I can do. I suppose some debugging is needed for u-boot and/or kernel. Hm, one more crazy idea: what if install the 5.65 (from SD and transfer to nand) first and upgrade to 5.75 on a running board? The idea is to upgrade kernel and system but not the u-boot. Not sure this is possible however...
  8. Ok, this kernel obviously can detect the USB drive. I've noticed USB could be initialized a little bit later than systemd tries to mount a root partition. On my board dmesg shows first ext4 mount at ~6s, whereas USB hub is inited at ~9.2s. Perhaps USB init is not yet completed in your case too. I doubt I can help with the exact root cause for this (whether this is u-boot issue or another reason). I would propose to delay the kernel boot for few seconds, maybe u-boot or armbian can be configured somehow to delay it. You can try also to reboot the board with reset key after the failed pendrive boot - just to check whether USB init is the reason (this might not help, but who knows...)
  9. Well, and what is the output of 2 more commands? # lsusb Bus 004 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 003 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 005 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub # ls -l /sys/bus/usb/devices/ total 0 lrwxrwxrwx 1 root root 0 Apr 30 21:51 1-0:1.0 -> ../../../devices/platform/soc@1c00000/1c14000.usb/usb1/1-0:1.0 lrwxrwxrwx 1 root root 0 Apr 30 21:51 2-0:1.0 -> ../../../devices/platform/soc@1c00000/1c1c000.usb/usb2/2-0:1.0 lrwxrwxrwx 1 root root 0 Apr 30 21:51 3-0:1.0 -> ../../../devices/platform/soc@1c00000/1c14400.usb/usb3/3-0:1.0 lrwxrwxrwx 1 root root 0 Apr 30 21:51 4-0:1.0 -> ../../../devices/platform/soc@1c00000/1c1c400.usb/usb4/4-0:1.0 lrwxrwxrwx 1 root root 0 Apr 30 21:51 5-0:1.0 -> ../../../devices/platform/soc@1c00000/1c13000.usb/musb-hdrc.1.auto/usb5/5-0:1.0 lrwxrwxrwx 1 root root 0 Apr 30 21:51 usb1 -> ../../../devices/platform/soc@1c00000/1c14000.usb/usb1 lrwxrwxrwx 1 root root 0 Apr 30 21:51 usb2 -> ../../../devices/platform/soc@1c00000/1c1c000.usb/usb2 lrwxrwxrwx 1 root root 0 Apr 30 21:51 usb3 -> ../../../devices/platform/soc@1c00000/1c14400.usb/usb3 lrwxrwxrwx 1 root root 0 Apr 30 21:51 usb4 -> ../../../devices/platform/soc@1c00000/1c1c400.usb/usb4 lrwxrwxrwx 1 root root 0 Apr 30 21:51 usb5 -> ../../../devices/platform/soc@1c00000/1c13000.usb/musb-hdrc.1.auto/usb5 Does the previous comment (ls phy@1c13400) match the log of "5.75 u-boot" log ? Can you see any USB device with this boot with lsusb?
  10. I suppose investigating of this issue needs better-than-mine understanding of low level details (u-boot, at least). I see some suspicious logs in u-boot: EHCI failed to shut down host controller. EHCI failed to shut down host controller. Also, the size of device tree decreased from 71000 (5.65) to 70000 (5.75) That's probably ok, but I would try to check the integrity of device tree. For example, the presence of the following node in the device tree (on running kernel): # ls /proc/device-tree/soc@1c00000/phy@1c13400/ '#phy-cells' clocks name pinctrl-0 reg reset-names status usb0_vbus-supply usb1_vbus-supply clock-names compatible phandle pinctrl-names reg-names resets usb0_id_det-gpio usb0_vbus_power-supply usb2_vbus-supply Please check this node if you can boot from SD card with 5.75.
  11. I've tried to compare u-boot's Bananapi_defconfig used by ARMBIAN 5.65 vs ARMBIAN 5.75 and there are just few small change which should not affect the boot (imho). Kernel was changed between 5.65 and 5.75 (the repository location and the version). My board is running ARMBIAN 5.73, kernel 4.19.20. It is booting from SSD connected on SATA (but u-boot is on SD, this A20 cannot boot from SATA or USB directly). An interesting point is: dmesg shows kernel had found and initialized USB hub. That's a little bit confusing as you've said 5.69 is not OK (I assume USB is not initialized). Unfortunately I cannot get u-boot log (I have only remote access to the board).
  12. Here we can see both u-boot and kernel can see the USB drive (pendrive log) scanning usb for storage devices... 1 Storage Device(s) found ... [ 6.517256] usb-storage 1-1:1.0: USB Mass Storage device detected ... [ 8.005130] sda: sda1 The kernel starts USB initialization at [ 5.731114] ehci-platform 1c14000.usb: EHCI Host Controller Absence of this init in the failed case could (imho) be caused by incorrect/damaged device tree. Device tree is loaded to memory by u-boot (and seems patched after this). I'm not familiar with u-boot in details, perhaps it uses the same device tree and this explains why it does not see storage device too. Although, this could be less important because u-boot seems load both kernel and device tree from SD (if I understand this boot process correctly). So the next step would be checking the device tree and presence of device at 1c14000.
  13. How do you know U-boot detects pendrive? from your log: scanning usb for storage devices... 0 Storage Device(s) found Can you get a (verbose) log from successive boot (I would prefer from "Armbian_5.65_Bananapi_Ubuntu_bionic_next_4.14.78.7z - Working")? I suppose there should be some report in the kernel log about partitions found, similar to mmc: [ 4.108295] mmcblk0: mmc0:aaaa SL16G 14.8 GiB [ 4.117872] mmcblk0: p1
  14. I would suspect kernel do not see USB device. There is no evidence it is detected. Perhaps log from successive boot could be compared against the faulty one to see the diff.
  15. No, it can be any bootable partition. Did you read the thread? I've showed the partitioning of SSD I've used to boot. The main issue with Armbian booting from SSD is that its uboot script does not correctly handle partitions. Check the diff.txt I've attached to my message of May 17. Unless you apply this somehow (build Armbian by yourself, for example), this booting from SSD won't work.