hanni76

  • Content Count

    133
  • Joined

  • Last visited

Everything posted by hanni76

  1. 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.
  2. 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 / #
  3. yes, it is visible... I can access it and list partitions.
  4. 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 O
  5. in my system I don't have uInitrd. can i proceed without it ? how should I execute mass storage script in this scenario?
  6. 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.
  7. 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
  8. @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 timeou
  9. @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 ?
  10. 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 fou
  11. 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
  12. Hello, guys, any plans to support SUBJ ? I need a very simple image, display + network. Thank you
  13. 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 f
  14. Finally resolved the issue. It was caused by an issue in custom device tree file which made linux boot fail silent.
  15. 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.
  16. 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
  17. 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
  18. 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
  19. Ok, the problem is Stretch release only. Stretch built on "hardware" host does not have any issue.
  20. 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.
  21. 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 60