• 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. Check 'cat /proc/device-tree/model' or other nodes under /proc/device-tree. This is the loaded device tree seen by kernel.
  2. 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)?
  3. 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...
  4. 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...)
  5. 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?
  6. 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.
  7. 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).
  8. 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.
  9. 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
  10. 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.
  11. 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.
  12. I've managed to build/install kernel headers correctly and build the wireguard manually. Here the is patch I've added to include absent headers (created a userpatches/kernel/rk3328-default/add_more_headers.patch), borrowed from https://github.com/armbian/build/commit/98fca07d8906555ebd419e2cd3eb2a5c0af80298 diff --git a/scripts/package/builddeb b/scripts/package/builddeb index b3ed160b..b776402f 100755 --- a/scripts/package/builddeb +++ b/scripts/package/builddeb @@ -323,6 +405,7 @@ fi # Build kernel header package (cd $srctree; find . -name Makefile\* -o -name Kconfig\* -o -name \*.pl) > "$objtree/debian/hdrsrcfiles" (cd $srctree; find arch/*/include include scripts -type f) >> "$objtree/debian/hdrsrcfiles" +(cd $srctree; find security -type f -name \*.h) >> "$objtree/debian/hdrsrcfiles" (cd $srctree; find arch/$SRCARCH -name module.lds -o -name Kbuild.platforms -o -name Platform) >> "$objtree/debian/hdrsrcfiles" (cd $srctree; find $(find arch/$SRCARCH -name include -o -name scripts -type d) -type f) >> "$objtree/debian/hdrsrcfiles" (cd $objtree; find arch/$SRCARCH/include Module.symvers include scripts -type f) >> "$objtree/debian/hdrobjfiles" This unfortunately does not fix the issue with dkms build (empty $SRCARCH), but build from sources is successful.
  13. How is your drive partitioned? I suppose the partition intended for booting should be marked with boot flag. Not sure whether nand-sata-setup is setting it. Uboot should be able to find the script first: scanning usb for storage devices... 1 Storage Device(s) found Device 0: Vendor: Samsung Rev: 8101 Prod: SSD 850 EVO 250G Type: Hard Disk Capacity: 238475.1 MB = 232.8 GB (488397168 x 512) ... is now current device Scanning usb 0:3... Found U-Boot script /boot/boot.scr BTW, I should say this booting is not as reliable as I wish. In my case device typically does not boot or hangs sometime time later. Most likely this is because power consumption of my drive is excessive, but perhaps USB init is also not reliable - if I start the device without the serial console (USB/TTL converter), device does not boot in 99% cases. If converter is attached - device boots on second-third attempt (with reset button), and works pretty good for a long time (this actually confuses me, because console does not provide any power, maybe device becomes slower.?..)
  14. Hi, I've built the Ubuntu 18.04 image with legacy kernel (4.4) and tried to install wireguard. The problem was the kernel module which seems to be build by dkms. I've installed kernel headers from the linux-headers-rk3328_5.44_arm64.deb (built by armbian's build procedure) and tried to install wireguard-dkms package. It fails: Unpacking wireguard-dkms (0.0.20180513-wg1~bionic) over (0.0.20180513-wg1~bionic) ... Setting up wireguard-dkms (0.0.20180513-wg1~bionic) ... Loading new wireguard-0.0.20180513 DKMS files... Building for 4.4.131-rk3328 Building initial module for 4.4.131-rk3328 Error! Bad return status for module build on kernel: 4.4.131-rk3328 (aarch64) Consult /var/lib/dkms/wireguard/0.0.20180513/build/make.log for more information. The content of make.log DKMS make.log for wireguard-0.0.20180513 for kernel 4.4.131-rk3328 (aarch64) Thu May 17 21:24:11 UTC 2018 make: Entering directory '/usr/src/linux-headers-4.4.131-rk3328' Makefile:643: arch//Makefile: No such file or directory make: *** No rule to make target 'arch//Makefile'. Stop. make: Leaving directory '/usr/src/linux-headers-4.4.131-rk3328' The line 643 is include arch/$(SRCARCH)/Makefile so SRCARCH is not set for some reason. Any suggestions how to fix it? Also I've tired to build wireguard module manually with dkms and/or from source. In both cases it fails because of absent scripts/recordmcount. I've tried to build that stuff with 'make scripts' in the /usr/src/linux-headers-4.4.131-rk3328 and this fails too: HOSTCC scripts/selinux/genheaders/genheaders scripts/selinux/genheaders/genheaders.c:13:10: fatal error: classmap.h: No such file or directory #include "classmap.h" This classmap.h exists in the kernel source tree, but was not included into kernel-headers deb. Do I need to fix something in kernel makefiles?
  15. Finally I was able to boot from SSD's partition. Attached is the patch for boot-rk3328.cmd. Steps: 1. Flash the ayufan's u-boot-flash-spi-rock64.img.xz to SD card, boot the device and wait for SPI bootloader flashed. 2. Flash the Armbian image (build with the patch) to SD card, boot the device with it 3. Login to a device, run nand-sata-install (copy rootfs to the selected SSD partition) , power off the device when finished. 4. Remove the SD card and boot the device. diff.txt