hanni76

hello, do you already have SUBJ ? Thank you

Yes, you were 100% right. I was able to overcome the issue by rewriting the driver a little bit so that the maximum transfer length is always the FIFO size.

Yes, it is mmcblk2 It looks better now (see below). Next question: how can I access this disk from the ubuntu host machine ? Starting kernel ... Loading, please wait... starting version 232 Begin: Loading essential drivers ... done. Begin: Running /scripts/init-premount ... Starting g_mass_storage script Exporting MMC 2 (eMMC) (/dev/mmcblk2) Done BusyBox v1.22.1 (Debian 1:1.22.0-19+b3) built-in shell (ash) Enter 'help' for a list of built-in commands. sh: can't access tty; job control turned off / #

should MMC driver be compiled as a module maybe ?

yes, it is visible... I can access it and list partitions.

hi zador I tried to boot and got some issues and below is my dmesg. First of all , it seems like eMMC is not visible as /dev/mmcblk1 with initramfs. When I boot normal mode it is present in the system. And second issue is that " /sys/bus/platform/devices/sunxi_usb_udc/otg_role" does not exist. Any ideas how to proceed ? U-Boot SPL 2018.03-rc1-dirty (Feb 14 2018 - 12:46:29 +0300) DRAM: 1024 MiB Trying to boot from FEL U-Boot 2018.03-rc1-dirty (Feb 14 2018 - 12:46:29 +0300) Allwinner Technology CPU: Allwinner H3 (SUN8I 1680) Model: Xunlong Orange Pi PC Plus DRAM: 1 GiB MMC: SUNXI SD/MMC: 0, SUNXI SD/MMC: 1 Loading Environment from FAT... Unable to use mmc 1:1... Failed (-5) Loading Environment from MMC... *** Warning - bad CRC, using default environment OK In: serial Out: vidconsole Err: vidconsole Net: phy interface0 eth0: ethernet@1c30000 starting USB... USB0: USB EHCI 1.00 USB1: USB OHCI 1.0 USB2: USB EHCI 1.00 USB3: USB OHCI 1.0 USB4: USB EHCI 1.00 USB5: USB OHCI 1.0 scanning bus 0 for devices... 1 USB Device(s) found scanning bus 2 for devices... 1 USB Device(s) found scanning bus 4 for devices... 1 USB Device(s) found scanning usb for storage devices... 0 Storage Device(s) found Hit any key to stop autoboot: 0 (FEL boot) ## Executing script at 43100000 ## Loading init Ramdisk from Legacy Image at 43300000 ... Image Name: uInitrd Image Type: ARM Linux RAMDisk Image (uncompressed) Data Size: 2783418 Bytes = 2.7 MiB Load Address: 00000000 Entry Point: 00000000 Verifying Checksum ... OK ## Flattened Device Tree blob at 43000000 Booting using the fdt blob at 0x43000000 Loading Ramdisk to 49d58000, end 49fff8ba ... OK Loading Device Tree to 49d4e000, end 49d572ba ... OK Starting kernel ... Loading, please wait... starting version 232 Begin: Loading essential drivers ... done. Begin: Running /scripts/init-premount ... Starting g_mass_storage script Exporting MMC 0 (SD) (/dev/mmcblk0) /scripts/init-premount/mass_storage: line 41: can't create /sys/bus/platform/devices/sunxi_usb_udc/otg_role: nonexistent directory /scripts/init-premount/mass_storage: line 46: can't create /sys/bus/platform/devices/sunxi_usb_udc/otg_role: nonexistent directory Done BusyBox v1.22.1 (Debian 1:1.22.0-19+b3) built-in shell (ash) Enter 'help' for a list of built-in commands. sh: can't access tty; job control turned off / #

ok, understood thank you

in my system I don't have uInitrd. can i proceed without it ? how should I execute mass storage script in this scenario?

Hi, can you please put more precise instructions on how to create binaries with mainline kernel? Is this possible to skip using initrd ? Thanks a lot.

Problem is fixed! Kernel 4.15 in sun7i-a20.dtsi for all nodes is using the following syntax soc@1c00000 but in my overlays it was soc@01c00000

@martinayotte I tried dtc -@. Here is my u-boot log U-Boot SPL 2017.11-armbian (Dec 24 2017 - 21:10:46) DRAM: 1024 MiB CPU: 912000000Hz, AXI/AHB/APB: 3/2/2 Trying to boot from MMC1 U-Boot 2017.11-armbian (Dec 24 2017 - 21:10:46 +0300) Allwinner Technology CPU: Allwinner A20 (SUN7I) Model: Banana Pi BPI-M1-Plus I2C: ready DRAM: 1 GiB MMC: SUNXI SD/MMC: 0 *** Warning - bad CRC, using default environment Setting up a 720x576i composite-pal console (overscan 32x20) In: serial Out: vga Err: vga SCSI: SATA link 0 timeout. AHCI 0001.0100 32 slots 1 ports 3 Gbps 0x1 impl SATA mode flags: ncq stag pm led clo only pmp pio slum part ccc apst Net: eth0: ethernet@01c50000 230454 bytes read in 155 ms (1.4 MiB/s) starting USB... USB0: USB EHCI 1.00 USB1: USB OHCI 1.0 USB2: USB EHCI 1.00 USB3: USB OHCI 1.0 scanning bus 0 for devices... 1 USB Device(s) found scanning bus 2 for devices... 1 USB Device(s) found scanning usb for storage devices... 0 Storage Device(s) found Autoboot in 1 seconds, press <Space> to stop switch to partitions #0, OK mmc0 is current device Scanning mmc 0:1... Found U-Boot script /boot/boot.scr 3708 bytes read in 213 ms (16.6 KiB/s) ## Executing script at 43100000 U-boot loaded from SD Boot script loaded from mmc 271 bytes read in 173 ms (1000 Bytes/s) 5264196 bytes read in 574 ms (8.7 MiB/s) 7193216 bytes read in 698 ms (9.8 MiB/s) Found mainline kernel configuration 39675 bytes read in 458 ms (84 KiB/s) 573 bytes read in 1331 ms (0 Bytes/s) Applying kernel provided DT overlay sun7i-a20-spi0.dtbo 1057 bytes read in 1358 ms (0 Bytes/s) Applying kernel provided DT overlay sun7i-a20-spidev.dtbo 267 bytes read in 1202 ms (0 Bytes/s) Applying kernel provided DT overlay sun7i-a20-brcmf.dtbo 269 bytes read in 1282 ms (0 Bytes/s) Applying kernel provided DT overlay sun7i-a20-ir-off.dtbo 5450 bytes read in 1224 ms (3.9 KiB/s) Applying kernel provided DT fixup script (sun7i-a20-fixup.scr) ## Executing script at 44000000 ## Loading init Ramdisk from Legacy Image at 43300000 ... Image Name: uInitrd Image Type: ARM Linux RAMDisk Image (gzip compressed) Data Size: 5264132 Bytes = 5 MiB Load Address: 00000000 Entry Point: 00000000 Verifying Checksum ... OK ## Flattened Device Tree blob at 43000000 Booting using the fdt blob at 0x43000000 Loading Ramdisk to 49afa000, end 49fff304 ... OK reserving fdt memory region: addr=43000000 size=70000 Loading Device Tree to 49a87000, end 49af9fff ... OK Starting kernel ...

@martinayotteOk, now I see it. I tested my overlays with configfs and they were accepted with no error. And so I'm assuming they are correct. I previously tried loading overlays compiled without -@ option and they failed to load by configfs. Let me ask you one more question: do you have any assumptions why valid overlays are not loaded by u-boot in "sunxi-dev" build ? The "sunxi-dev" is using the same u-boot 2017.11 as "sunxi-next" with full list of patches. Why shouldn't it load my VALID overlays ?? Can this somewhat depend on patches applied to the kernel itself ?

Hi again, I have recompiled sunxi-next with "add-configfs-overlay-for-v4.10.x.patch" disabled. My overlays are still working fine! Any ideas? @Igor @zador.blood.stained maybe someone else can remember how overlays are actually loaded in runtime and what patch do I need ?? I have maid more experiments (full cleanup & rebuild & check /sys/kernel/config/ directory) with the same results : "sunxi-next" overlays are loaded WITHOUT configfs. I am still digging into it yourself but any help will be very much appreciated! @martinayotte I just found in your answer that it maybe u-boot which is loading overlays and configfs.c is not required to load overlay listed in armbianEnv.txt, correct ?

Hi,thank you. As far as I know armbian has support for some boards with A64 chip, it is sun50i, isn't it ? SO the problem here only in firmware, correct ? U-boot has support for nanopi a64 too. According to this resource http://linux-sunxi.org/Linux_mainlining_effort there is a basic support for the board since 4.14

Hello, guys, any plans to support SUBJ ? I need a very simple image, display + network. Thank you

Thanks for reply but I don't feel I can do a painless backport of drm display engine, it seems complex to me. Thanks, martinayotte does this mean if I rewrite configs.c file for 14.5 (there shouldn't be too much work, as far as I can see) then overlays should start loading ? I wonder why it works WITHOUT configs in sunxi-next. This is my big question. I confirm again that it works. I mean I normally set "overlays=bla bla" in armbianEnv.txt file and they load and work. with no configfs.c compiled! wait... I have an idea.. maybe configfs is deployed from previous builds ? I don't think I did a specific cleanup there in addition to the mandatory cleanup which is done before every build. ok, I see now. configs is compiled into kernel, it is not a module. that's why it is still in the kernel and overlays work Yes, it makes sense. I'll see if I can do that. But I am afraid that might be much more complicated task for me than analyzing your patches that I have directly on my hard drive. I can apply them 1 by 1 as soon as I need them.

Finally resolved the issue. It was caused by an issue in custom device tree file which made linux boot fail silent.

The issue still exists with sunxi-dev (kernel 4.15) and sun7i-a20. I've already verified all things that in my opinion might be a cause of the problem but I haven't found a solution yet. I've also found that the ability to load overlays in run-time does NOT depend on CONFIG_OF_CONFIGFS. I've tested this by switching off this functionality in sunxi-next build: my OrangePi PC is still able to load overlays without configfs. I think I am going to do a printk-debug soon in overlay-related code.

Hello guys can you help me please understand your overlay compilation support which is working in "next" build? I transferred required patches and made a build with 4.15. Now I have my dtbos and scr in place, added "overlays=" in armbianEnv.txt but my overlays are not loaded in run-time. I noticed that you have the following condition around dtbos: ifeq ($(CONFIG_OF_CONFIGFS),y) ... endif and there is also a special patch to add configs module to build. My question: is configs module required for loading overlays ? I can't apply this patch into 4.15 as configfs.c is not compatible with new codebase. Here is my patches https://github.com/orpaltech/antenna-analyzer-armbian/blob/master/build/userpatches/kernel/sunxi-dev/Add-overlay-compilation-support.patch https://github.com/orpaltech/antenna-analyzer-armbian/blob/master/build/userpatches/kernel/sunxi-dev/board_bananapim1plus/Add-sun7i-a20-overlays.patch Thanks

Processing file /home/user/Projects/armbian/build/patch/u-boot/u-boot-sunxi/fix-sunxi-gpio-driver.patch patch unexpectedly ends in middle of line

Hello, guys, I need your help with building an image with kernel 4.15 ("dev") for bananapi m1+ (can't use "next" because I need the new display engine). First of all, I need to transfer patches from 4.14 so that I can create my own overlays. Can you tell me which patches I need to look at , besides "add-overlay-compilation-support.patch" ? Thank you

Ok, the problem is Stretch release only. Stretch built on "hardware" host does not have any issue.

Hardware host, Ubuntu 16.04, produces working images. So the problem exists only in Virtualbox. IMAGES (without any customization) CREATED IN VIRTUALBOX DO NOT BOOT. i.e. Virtualbox can't be considered as a reliable platform for building Armbian images. At least until I find a reason why this happens.

Samba share is not a problem.

Here is log file from "hardware" host: ------------------------ [ o.k. ] Free space: [ SD card ] Filesystem Size Used Avail Use% Mounted on udev 5,9G 0 5,9G 0% /dev tmpfs 1,2G 27M 1,2G 3% /run /dev/sda4 156G 22G 126G 15% / tmpfs 5,9G 171M 5,7G 3% /dev/shm tmpfs 5,0M 8,0K 5,0M 1% /run/lock tmpfs 5,9G 0 5,9G 0% /sys/fs/cgroup /dev/sda5 170G 97G 64G 61% /home/sergey/Projects /dev/sda6 92G 68M 87G 1% /home/sergey/Public /dev/sda7 105G 60M 100G 1% /home/sergey/Projects2 tmpfs 1,2G 100K 1,2G 1% /run/user/1000 tmpfs 7,8G 314M 7,5G 4% /home/sergey/Projects/armbian/build/.tmp/rootfs-next-orangepipc-stretch-no /dev/loop0p1 547M 320M 205M 61% /home/sergey/Projects/armbian/build/.tmp/mount-next-orangepipc-stretch-no