Jump to content

hanni76

Members
  • Posts

    133
  • Joined

  • Last visited

Posts posted by hanni76

  1. 3 hours ago, zador.blood.stained said:

    It's the same driver that is used for SD, but eMMC may appear, for example, as /dev/mmcblk2 (which is not accounted in the default script)

    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
    / # 
     

     

  2. 22 hours ago, zador.blood.stained said:

    Then you need to make one (update-initramfs + mkimage), even if it won't be used by the normal system boot. You'll need to have a ramdisk with busybox if you want to execute any script.

     

    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
    / # 
     

     

  3. On 2/10/2018 at 5:27 PM, zador.blood.stained said:

    Everything is possible if you dig deep enough into the kernel patching. Or using u-boot OTG + fastboot if the target platform supports this - this way you wouldn't need to load anything except for the u-boot.

     

    There won't be much differences from the legacy binaries, you would need to provide a DT blob instead of script.bin and make sure that OTG is running in the device mode (either by patching the DT or by relying on the OTG ID pin).

    There are no step by step instructions for creating those binaries, for a PoC it is enough to extract u-boot, zImage, uInitrd and .dtb file from a working image and add the mass storage script to initrd.

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

  4. On 1/11/2017 at 4:33 PM, zador.blood.stained said:

    Simply copied from a working image after adding mass_storage script to the initrd and recompiling it. Ideally this needs to be redone based on the mainline kernel (and it will be universal for A10, A20 and H3 devices).

    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.

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

  6. @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 ?

  7. On 12/22/2017 at 4:32 PM, martinayotte said:

    Without CONFIG_OF_CONFIGFS, you won't have the sysfs location /sys/kernel/config/device-tree/overlays, so you won't be able to load overlays AFTER the kernel has booted, but this doesn't prevent U-Boot been able to load some overlays BEFORE the kernel been booted.

     

     

    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 ?

  8. 1 hour ago, guidol said:

    armbian isnt available, but a Ubuntu 16.04 xenial with LXDE-Desktop at:

    Welcome to Ubuntu 16.04.3 LTS (GNU/Linux 3.10.105 aarch64) Linux nanopi-a64 3.10.105 #1 SMP PREEMPT Mon Mar 27 10:59:50 BRT 2017 aarch64 aarch64 aarch64 GNU/Linux

    https://github.com/avafinger/nanopi-a64-firmware

     

    see also:
    http://www.friendlyarm.com/Forum/viewtopic.php?f=53&t=992

    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

  9. 7 hours ago, Igor said:


    We have no plans to adjust those patches for anything > 4.14.y in next couple of months. As you can see there is currently a big mess with patches for NEXT and that has to be sorted before we can move further. I don't see a point to mess with this right now.

     

    IMHO if you need some functionality from higher kernels, rather backport to 4.14.y since this will be the next LTS build. Also first stable build for H3/H6&A64 ... when we are that far.

    Thanks for reply

    but I don't feel I can do a painless backport of drm display engine, it seems complex to me. 

     

    2 hours ago, martinayotte said:

    Without CONFIG_OF_CONFIGFS, you won't have the sysfs location /sys/kernel/config/device-tree/overlays, so you won't be able to load overlays AFTER the kernel has booted, but this doesn't prevent U-Boot been able to load some overlays BEFORE the kernel been booted.

     

    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

     

    7 hours ago, Igor said:


    We have no plans to adjust those patches for anything > 4.14.y in next couple of months. As you can see there is currently a big mess with patches for NEXT and that has to be sorted before we can move further. I don't see a point to mess with this right now.

     

    IMHO if you need some functionality from higher kernels, rather backport to 4.14.y since this will be the next LTS build. Also first stable build for H3/H6&A64 ... when we are that far.

    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.

  10. 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.

  11. 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

     

  12. 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.

  13. 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

     

     

     

×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines