divis1969

Members
  • Content count

    37
  • 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. divis1969

    [Rock64] Cannot install wireguard module on Ubuntu 18.04

    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.
  2. divis1969

    Rock64 boot from SSD/HDD (attached via USB)

    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.?..)
  3. 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?
  4. divis1969

    Rock64 boot from SSD/HDD (attached via USB)

    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
  5. divis1969

    Rock64 boot from SSD/HDD (attached via USB)

    After some debugging I suppose the armbian's boot.scr seems completely ignore the boot partition number specified by ${distro_bootpart}. In case of SD card boot it is equal 1 and this I suppose is the default value for operations like 'load ${devtype} ${devnum} ...'
  6. divis1969

    Rock64 boot from SSD/HDD (attached via USB)

    The "some utility from ambian-config" from my initial post seems exactly this nand-sata-install. I've also tried it after SPI boot is flashed first. The results are the same.
  7. Hi, Is it possible to boot from SSD? How it should be partitioned? Can I use any arbitrary partition for rootfs? Should I follow the procedure from this thread ? It assumes I should write the armbian image to a whole drive instead of partition, right? Well, I actually tried some way... First, I've tried to just run some utility from ambian-config that transfers rootfs to a partition. Device did not boot after this (with SD card ejected). Then I've flashed the ayufan's u-boot-flash-spi-rock64.img.xz. This also fails (boot log is attached) but the log looks promising. BTW, I'm experimenting with Ubuntu 18.04 image built by myself from armbian's development branch. Should I use 16.04 instead? Does armbian have its own image/procedure to place uboot into SPI? Just in case here is the drive partitioning (fdisk log from Linux PC): Disk /dev/sde: 232.9 GiB, 250059350016 bytes, 488397168 sectors Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 4096 bytes I/O size (minimum/optimal): 4096 bytes / 33553920 bytes Disklabel type: dos Disk identifier: 0x22138112 Device Boot Start End Sectors Size Id Type /dev/sde1 2048 119769087 119767040 57.1G 83 Linux /dev/sde2 156354560 488396799 332042240 158.3G 83 Linux /dev/sde3 * 119769088 156354559 36585472 17.5G 83 Linux Partition table entries are not in disk order. And I'm trying to use third partition for rootfs. This partition was actually created after shrinking partition 1 in the freed space. Drive is attached to USB3. minicom.cap
  8. I've tried to install GitLab onto Banana PI running Armbian (Ubuntu 16.04 server). I've followed the instructions for Raspberry PI (on https://docs.gitlab.com/omnibus/manual_install.html) and generic https://about.gitlab.com/installation/#ubuntu Unfortunately this fails: $curl -s https://packages.gitlab.com/install/repositories/gitlab/raspberry-pi2/script.deb.sh | sudo bash ... $ sudo EXTERNAL_URL="http://myurl.com" apt-get install gitlab ... Verifying we have all required libraries... Could not find gem 'devise-two-factor (~> 2.0.0)' in any of the gem sources listed in your Gemfile or available on this machine. Did anybody tried the same? Is there any way to fix the issue?
  9. divis1969

    BPI-M3 build

    Hm, CLEAN_LEVEL="debs" FORCE_CHECKOUT=no (or maybe FORCE_CHECKOUT=no only?) do the trick. It looks like config/kernel/linux-sun8i-dev.config limits the core number (CONFIG_NR_CPUS=4). What is the correct way for armbian to define it as 8 and did not break other plaforms?
  10. divis1969

    BPI-M3 build

    Assuming I've already built the code, how can I re-build the armbian with no code checkout/reset and no patch applied? I need to alter the DTS directly in the kernel source with patches applied before.
  11. divis1969

    BPI-M3 build

    armbianmonitor -u: http://sprunge.us/GGRN Pull requiest: https://github.com/armbian/build/pull/734 As for the thermal sensor, it looks like thermal zone needs appropriate device tree implementation, similar to this: https://github.com/wens/linux/blob/sunxi-next/arch/arm/boot/dts/sun8i-a33.dtsi#L276 https://github.com/wens/linux/blob/sunxi-next/arch/arm/boot/dts/sun8i-a33.dtsi#L394 Nobody seen such patch for a83t?
  12. divis1969

    BPI-M3 build

    Ok, I'll collect it. I was able to change the root passwd, add new user (from the debug console) and was able later to connect/login the device by ssh. Ok. Actually, the change will need significant corrections - I did not try to modify the patches (that are mostly applicable for other devices), I simply removed those files. And I suppose I wont be able to do this correctly. I have one more issue: I've tried to upgrade the device (sudo apt update; sudo apt upgrade) and this seems replaced the kernel and dtb packages (and device does not boot again). How can I prevent this? Should I modify the locally built package version somehow?
  13. divis1969

    BPI-M3 build

    Thanks! This repo is ok: patches applied successfully (though I had deleted most of the patches provided by Armbian, except the packaging-4.x-DEV-with-postinstall-scripts.patch which was corrected a little). I've built Armbian (console Xenial) and network works pretty good. Did not find any file under /sys/class/thermal/ Perhaps it needs to be ported from somewhere. Was it implemented somewhere already? In Sinovoip 3.4 maybe?
  14. divis1969

    BPI-M3 build

    I'm wondering are those patches from Patchwork are applicable to some specific git repo, branch? I'v tried to apply patches for bananapi m3 (https://patchwork.kernel.org/patch/9762011/, https://patchwork.kernel.org/patch/9762017/, https://patchwork.kernel.org/patch/9762019/, https://patchwork.kernel.org/patch/9762021/) to vanilla kernel, but the last one fails: Error: arch/arm/boot/dts/sun8i-a83t-bananapi-m3.dts:87.1-6 Label or path mmc0 not found Error: arch/arm/boot/dts/sun8i-a83t-bananapi-m3.dts:97.1-6 Label or path mmc2 not found Obviously it depends on some specific version of sun8i-a83t.dtsi, but I do not know how/where to get it. Should I try to find appropriate patch in this Patchwork?
  15. divis1969

    BPI-M3 build

    Thanks for the tip. I've tried to modify the patch for m3 to include this patch. The build is ok, kernel log does not show any issue while booting, but the board seems dos not get the IP via DHCP (I cannot see it on a router). I will try to get the logs from the board (I did not try yet simultaneously connect to debug port and attach the network cable), perhaps it will give me some clue. Actually, I did modified the patch to match the 4.11 version of a83 DTS. But the original patch seems for the mainline kernel. I'm wondering, can I build it instead of the 3rd party dev kernel currently used by m3 WIP? Is is enough to replace the URL of the kernel repo?