Jump to content

linda

Members
  • Posts

    49
  • Joined

  • Last visited

Posts posted by linda

  1. Thank you very much for the quick help.
    I changed my existing image with the armbian-config-tool to the 'next'-kernel and now I have the kernel 1.14 in operation. Great!

    In addition I also created a new image yesterday, I will test this image and the possible options in the next few days.

  2. Hello,
    I'm using an pine64 with the old mainline Ubuntu server (version 5.32.170911, kernel 4.13) for my project.
    Thanks for the great work for the Pine64-Armbian!

    I would like to change to a new image LTS kernel 4.14, because the existing kernel version is no longer supported.
    Unfortunately I only find the Debian Stretch version on the mainline kernel download server.

     

    Is it possible to get a new image with Mainline kernel 4.14 and Ubuntu server?

     

    and if not:
    - If there is no image with 4.14 Ubuntu server, can I change from legacy ubuntu to kernel 4.14?

     

    By the way, why ist the mainline-version using debian stretch, but legacy uses Ubuntu? How is the development planned further?

    I would really appreciate an answer.

  3. Thanks a lot for your answers and especially for the suggestion to change the boot.cmd.

     

    As proposed, I changed two lines concerning the fdtname in the the boot.cmd:

        "load ${devtype} 0 ${fdt_addr_r} ${prefix}dtb/${fdtfile}"

     

    but leave these line concerning the overlay-setting unchanged

         "if load ${devtype} 0 ${load_addr} ${prefix}dtb/allwinner/overlay/${overlay_prefix}-${overlay_file}.dtbo; then"

         "if load ${devtype} 0 ${load_addr} ${prefix}dtb/allwinner/overlay/${overlay_prefix}-fixup.scr; then"

     

    and recompile boot.cmd.

     

    This works for me, also with the allwinner overlay dtbo-file.

  4. Hello,

    today I made an upgrade of my pine64-mainline and failed miserably - my new armbian image won't boot any more.

     

    So I did some more tests with a new more different sd-cards, power supply and the mailine kernel form the download site (https://dl.armbian.com/pine64/Ubuntu_xenial_dev_nightly.7z): Again, the same behaviour, the image doesn't bott any more after "apt update" and "apt upgrade".

     

    Please, could someone help me with this problem?

    I hope these lockup logs help in troubleshooting. Thanks a lot!

     

    boot-fail-2017-09-06-A.log

    boot-fail-2017-09-06-B.log

  5. Thank you for the information about the nightly builds.

     

    Perhaps I'm wrong, but I thought I'm using the beta repsoitory in the case of mainline kernel

    ("deb http://beta.armbian.com xenial main utils xenial-desktop")

     

    The update standard way ("apt upgrade") installed this version "Linux pine64 4.11.10-sun50iw1 #3 SMP Thu Aug 3 11:15:06 CEST 2017",

     - as fas as I can see this kernel doesnt't include he modification above, so the upper usb port doesn't work.

     

    I would like to thank very much for the help regarding the usb port and I'm looking forward to try the new version.

    Do I have to use another repository (or upgrade settings?) to obtain newest kernel with the commit above?

     

  6. First of all: Thank you very much and of course you are right, it's reversed.

     

    Unfortunatly I'm not able to build my own kernel.

    Therefore I have to ask you when a kernel with this commit will be availabe for testing.

    [I can only upgrade to the kernel: "Linux pine64 4.11.10-sun50iw1 #3 SMP Thu Aug 3 11:15:06 CEST 2017"

     

    I was under the impression that there were nightly builds but I can't find any newer version in this directory (https://dl.armbian.com/pine64/nightly/)

  7. I read in the documentation for the mainline kernel that the upper USB port is configured as OTG by default.
    ("It’s possible to convert the upper USB port (normally an OTG port) into a full USB host port using an own PHY by setting some magic bits.")
    See also the post of thkaiser: https://forum.armbian.com/index.php?/topic/1917-armbian-running-on-pine64-and-other-a64h5-devices/&tab=comments#comment-15074

    Because I can use the upper USB port, I assume the "magic bits" were configured.


    But I had problems with the lower USB-Port. The output of "lsusb" gave me:
    Bus 002 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
    Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

     

    (while the output of "lsusb" with the legacy kernel is
    Bus 004 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
    Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
    Bus 003 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
    Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub)

     

    So if I connect a USB-device to the upper USB port, the device is identified correctly.
    But if I connect an usb device to the lower USB port, nothing happens.

     

  8. Hi,

    I've changed the default console from ttyS0 to ttyS3, using the mainline kernel with overlay "/boot/dtb/allwinner/overlay/sun50i-a64-uart3.dtbo".

     

    Unfortunately when I run command "sudo shutdown -r now" (or sudo reboot) my pine shuts down instead of reboot (although the console output says "reboot: Restarting system" at the end.)

    [Hard reset reboot works with "reboot -f" using ttyS3 console].

     

    Using the standard console I can reboot my pine without problems.

     

    What could case this behavior? Is it necessary to disable or kill a ttyS3-process before the reboot?

  9. Thank you very much for pointing me in the right direction.

    I wasn't aware of the possibility to apply overlays to the device tree.

    And I didn't want to change the master DT because of loosing my changes in case of updates coming from armbian.

     

    Consulting the armbian documentation https://docs.armbian.com/User-Guide_Allwinner_overlays/

    I found out there are already overlays supplied for various purposes and I just used: "/boot/dtb/allwinner/overlay/sun50i-a64-uart3.dtbo".

     

    After activating the overlay in "ArmbianEnv.txt" I was done. Great!

     

     

     

     

     

  10. Hi,

    I've tried to change the default console from ttyS0 to ttyS3, using the mainline kernel but I don't get it to work.

     

     

    Modifying boot.cmd I managed to change the tty's baudrate like this:

    "if test "${console}" = "serial" || test "${console}" = "both"; then setenv consoleargs "${consoleargs} console=ttyS0,38400"; fi"

     

    after recompiling with "mkimage -C none -A arm -T script -d /boot/boot.cmd /boot/boot.scr"

    it gave me an 38400-baud-output begining with line "Loading, please wait...starting version 229"

     

    But changing the settings to use ttyS3 does not work at all:

    "if test "${console}" = "serial" || test "${console}" = "both"; then setenv consoleargs "${consoleargs} console=ttyS3,38400"; fi"

    after recomililation ttyS3.is simply dead.

     

    Using the following string works like a charm with the legacy kernel!

    "if test "${console}" = "serial" || test "${console}" = "both"; then setenv consoleargs "${consoleargs} console=ttyS3,38400n8"; fi"

    (The "n8" suffix after the baudrate does not seem to matter at this point.)

     

    I tested the following armbian versions with the same result.

    5.27.170614 nightly Ubuntu 16.04.2 LTS 4.11.1-sun50iw1  and

    5.31.170619 nightly Ubuntu 16.04.2 LTS 4.11.1-sun50iw1

     

     

     

  11. I did some more tests with more different sd-cards: Another brand 8GB, 4GB and one 16GB card.

    The results were quite the same as before. About 80% successfully booting.


    After equipping my pine boards with a reset-switch i did the following test:
    if the board fails to boot after 50 seconds -> press the reset switch.
    With the  5.27 image the boards had an rate of successfully booting of 99% after the second reset.  

    Summary
    260 attempts to boot (power on)
    204 success (78%)
    251 success after one reset 96%
    258 success after two resets 99%

    Are there any more test I could make or any information I could provide in order to support you?

     

    Will the 5.27 image become available via standard apt-upgrade?
    If so, when do you think this will be going to happen?

     

  12. I have now done another 120 boot attempts with the 4GB SD cards and achieved the following results:
    - The boot-success was 80%.
    - The lockup files show similar results as before, but are slightly different (see appendix):

     

    For example

    One boot failure showed the following behavior:

    [   14.834515] Freeing unused kernel memory: 524K (ffffffc0009fc000 - ffffffc000a7f000)
    Loading, please wait...
    starting version 229
    [   15.262882] [DISP] disp_device_attached_and_enable,line:159:attched ok, mgr0<-->device1, type=4, mode=5
    Begin: Loading essential drivers ... done.
    Begin: Running /scripts/init-premount ... done.
    Begin: Mounting root file system ... Begin: Running /scripts/local-top ... done.
    Begin: Running /scripts/local-premount ... done.
    Begin: Will now check root file system ... fsck from util-linux 2.27.1
    [/sbin/fsck.ext4 (1) -- /dev/mmcblk0p1] fsck.ext4 -a -C0 /dev/mmcblk0p1  
    /dev/mmcblk0p1: recovering journal
    /dev/mmcblk0p1: clean, 47463/216832 files, 368808/915968 blocks
    done.
    [   41.122365] BUG: soft lockup - CPU#0 stuck for 22s! [kworker/0:1:35]

     

    one boot failure started with

    [   14.378982] Freeing unused kernel memory: 524K (ffffffc0009fc000 - ffffffc000a7f000)
    Loading, please wait...
    starting version 229
    [   36.758677] BUG: soft lockup - CPU#0 stuck for 22s! [kworker/0:1:35]

     

    and another boot failures followed these boot-outputs

    [   14.405592] Freeing unused kernel memory: 524K (ffffffc0009fc000 - ffffffc000a7f000)
    starting version 229
    [   14.487651] hub 3-0:1.0: USB hub found
    [   14.496552] hub 3-0:1.0: 1 port detected
    [   14.505686] scene_lock_init name=ohci_standby
    Begin: Loading essential drivers ... done.
    Begin: Running /scripts/init-premount ... done.
    Begin: Mounting root file system ... Begin: Running /scripts/local-top ... done.
    Begin: Running /scripts/local-premount ... done.
    Begin: Will now check root file system ... fsck from util-linux 2.27.1
    [   14.916161] [DISP] disp_device_attached_and_enable,line:159:attched ok, mgr0<-->device1, type=4, mode=5
    [/sbin/fsck.ext4 (1) -- /dev/mmcblk0p1] fsck.ext4 -a -C0 /dev/mmcblk0p1  
    /dev/mmcblk0p1: recovering journal
    /dev/mmcblk0p1: clean, 47374/216832 files, 347125/915968 blocks
    done.
    [   40.716572] BUG: soft lockup - CPU#0 stuck for 22s! [kworker/0:1:35]

     

     

    I hope these lockuo logs help in troubleshooting. Thanks aBOOTFail_2017-04-15-B1.log lot!!

    BOOTFail_2017-04-15-B2.log

    BOOTFail_2017-04-15-C1.log

  13. Sorry, I've picked up the wrong package.

    Now I have installed the linux-image package and carried out first boot-tests with a 4GB-SD-card.

     

    And the result was great, 90% success, my pine64 started up almost every time.

    I will continue the tests in the next days.

    Thank you, you have done me a big favor.

  14. Unfortunately the Pine64 continues failing to boot with the actual armbian version.
    Finally I did a few tests concerning the boot problem, using different SD cards.
    I used the current Ubuntu server version (Armbian_5.25_Pine64_Ubuntu_xenial_default_3.10.104), upgrade 11.04.17). With
    only Ethernet and Power connected
    (no HDMI, no USB device, ...). Power was supplied through Pin Headers (not micro USB)
    Ethernet used DHCP. I used three different Pine64+ boards with 2GB of RAM for my tests.

     

    Results:
    The boot problem - Pine64 does not boot completely - continued to occur at different frequency depending on the SD-card used:

    - With the 4GB cards the Pine64 booted only in 46% of the cases (90 tests).
    - With the 8GB cards
    the Pine64 booted in 90% of the cases (60 tests).

    - With the 32GB cards the Pine64 booted in 50% of the cases (60 tests).

     

    The boot console shows the following behavior - similar to the post of christf -:

    Begin: Loading essential drivers ... done.
    Begin: Running /scripts/init-premount ... done.
    Begin: Mounting root file system ... Begin: Running /scripts/local-top ... done.
    Begin: Running /scripts/local-premount ... done.
    Begin: Will now check root file system ... fsck from util-linux 2.27.1
    [   14.723973] [DISP] disp_device_attached_and_enable,line:159:[/sbin/fsck.ext4 (1) -- /dev/mmcblk0p1] fsck.ext4 -a -C0 /dev/mmcblk0p1 
    /dev/mmcblk0p1: clean, 47357/216832 files, 366370/915968 blocks
    done.
    attched ok, mgr0<-->device1, type=4, mode=5
    
    

     

    And than it then continually repeats....

    [   40.681832] BUG: soft lockup - CPU#0 stuck for 22s! [kworker/0:1:35]
    [   40.693596] Modules linked in:
    [   40.701616] 
    [   40.707811] CPU: 0 PID: 35 Comm: kworker/0:1 Not tainted 3.10.104-pine64 #2
    [   40.720179] Workqueue: events start_work
    [   40.729239] task: ffffffc078b1a4c0 ti: ffffffc078b74000 task.ti: ffffffc078b74000
    [   40.742218] PC is at __do_softirq+0xb4/0x2d8
    [   40.751573] LR is at __do_softirq+0x30/0x2d8
    [   40.760848] pc : [<ffffffc0000b5fc4>] lr : [<ffffffc0000b5f40>] pstate: 40000145
    .... 
    

     

     

    I hope anyone can give me an idea on how to solve the problem.

    Thanks a lot.

     

    BOOTFail.log

  15. I am using Armbian (Server 5.24, Legacy 3.10.104) on the Pine64 and it is a great system. Unfortunately, I also encounter this boot problem, about every third time it fails to boot (repeating "Call trace: ...)

     

    Is there anything I can do???

    I have already checked the power supply.

    Can i use other versions of dtb-files oder kernel?

     

    Thanks a lot.

×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines