Jump to content

divis1969

Members
  • Posts

    67
  • Joined

  • Last visited

Everything posted by divis1969

  1. 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).
  2. 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.
  3. 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
  4. 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.
  5. 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.
  6. 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.
  7. 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.?..)
  8. 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?
  9. 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
  10. 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} ...'
  11. 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.
  12. 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
  13. 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?
  14. 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?
  15. 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.
  16. 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?
  17. 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?
  18. 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?
  19. 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?
  20. 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?
  21. It looks I was not patient to wait for first boot complete. I've set 'verbose=7' in armbianEnv.txt and now can boot to login screen (though I cannot log in, something wrong with TXD on my USB/Serial dongle). I've tried to log in via ssh, but was not able to do this. Kernel logs shows there is an error while initializing the Ethernet driver [ 4.613168] sun8i-emac 1c30000.ethernet (unnamed net_device) (uninitialized): Could not find a MDIO node [ 4.622735] sun8i-emac: probe of 1c30000.ethernet failed with error -22 Most likely the a83 DTS is not correct. For example, H3 dts : emac: ethernet@1c30000 { compatible = "allwinner,sun8i-h3-emac"; syscon = <&syscon>; reg = <0x01c30000 0x104>; interrupts = <GIC_SPI 82 IRQ_TYPE_LEVEL_HIGH>; resets = <&ccu RST_BUS_EMAC>; reset-names = "ahb"; clocks = <&ccu CLK_BUS_EMAC>; clock-names = "ahb"; #address-cells = <1>; #size-cells = <0>; status = "disabled"; mdio: mdio { #address-cells = <1>; #size-cells = <0>; int_mii_phy: ethernet-phy@1 { reg = <1>; clocks = <&ccu CLK_BUS_EPHY>; resets = <&ccu RST_BUS_EPHY>; }; }; }; Whereas A83: emac: ethernet@1c30000 { compatible = "allwinner,sun8i-a83t-emac"; reg = <0x01c30000 0x104>, <0x01c00030 0x4>; reg-names = "emac", "syscon"; interrupts = <GIC_SPI 82 IRQ_TYPE_LEVEL_HIGH>; clocks = <&bus_gates 17>; clock-names = "ahb"; resets = <&ahb_reset 17>; reset-names = "ahb"; #address-cells = <1>; #size-cells = <0>; }; Does anybody know where can I get the correct DTS for A83 emac driver?
  22. I've fixed this, U-boot passed this, but stuck (see log) at Scanning for Btrfs filesystems minicom.cap
  23. It looks like the patch failed: Processing file /parentroot/devel/project/bananapi/armbian/lib/patch/kernel/sun8i-dev/board_bananapim3/a83t-banana-m3.patch 1 out of 1 hunk FAILED -- saving rejects to file arch/arm/boot/dts/Makefile.rej
  24. I've finally started to debug the Armbian build (flashed to SD) with console. RIght before this I've flashed the emmc with the 'minimal-preview' image from BPI (http://forum.banana-pi.org/t/bpi-m3-new-image-ubuntu-16-04-xenial-minimal-preview-bpi-m3-img-2016-07-10/1988) Am I right U-Boot is trying to boot from it (see the attachment)? U-boot loaded from SD Boot script loaded from mmc If so, is it possible to switch back to SD boot without cleaning the emmc? minicom.cap
  25. Is it possible to provide more details? I'm not familiar with uboot (yet), but how this could affect the kernel start up? As for the kernel - the same question: what features could prevent armbian to boot?
×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines