mboehmer

Members
  • Content Count

    110
  • Joined

  • Last visited

 Content Type 

Forums

Member Map

Store

Crowdfunding

Raffles

Applications

Calendar

Posts posted by mboehmer


  1. 12 hours ago, jjjbenderjjj said:

    Our [CPU] doesn't have [SVE]. Please somebody proves me wrong!

    Hm. How about starting with the existing problems (like the 1.8V/3.3V switching for the uSD card), before you try to find out something about the CPU instruction set?

    A system not being able to properly reboot with uSD card will not be of use forf anyone.

    Seems like you know what you are doing, so you help us here.


  2. 17 hours ago, jjjbenderjjj said:

    Can somebody write the output of the commands for 5.4 kernel. It would be very helpful for me (I try to figure out is there SVE or not in this CPU)

    • uname -a
    • cat /proc/cpuinfo
    • lshw

    Thx you all in advance.

    For 5.6 kernel attached. I have no 5.4 system running,. Hope it helps nevertheless.

    5.6.txt


  3. On 6/23/2020 at 3:02 AM, Technicavolous said:

    @mboehmer I've rebooted my C4 over and over with several downloaded images,  I've not had a single stick. Finally compiled my own image. Sticks every time on shutdown -r now.  

    I have the Hardkernel eMMC 16GB, but also tried Sandisk 32GB U3.  I am using lab power supplies ...

    Which kernel / Uboot did you use for compiling?  I assume you compiled a complete image?

    WIth eMMC reboot works like a charm (tried Hardkernel eMMC 16GB, as well as Radxa ones), with uSD cards it fails every time.

     

    I assume we need to make sure that Uboot switches the card to 3.3V mode during startup. Putting this into the kernel is dangerous, as the reboot may or may not happen by software.


  4. Some news: it is not the TEST_N pin. There is no pulse or noise visible which could reset the CPUs.

    I will check the VDDIO_AO next, which could cause a reset also.

    Only glitch so far I have seen: Amlogic recommends a 1nF cap on RESET_N line, which is missing in the C4.

     

    Can anyone explain at what point of the boot sequence the "SM1:" message is being generated? Any clues for a reset source hitting here?


  5. If you take a look on my previous post, it looks like the bootloader starting, and then being broken by a reset, immediately following a new boot attempt.

     

    The "normal" boot messages are like that (cold starting a 5.x kernel from uSD card):

    SM1:BL:511f6b:81ca2f;FEAT:A0F83180:20282000;POC:F;RCY:0;EMMC:800;NAND:81;SD?:0;SD:0;READ:0;0.0;CHK:0;
    bl2_stage_init 0x01
    bl2_stage_init 0x81
    hw id: 0x0000 - pwm id 0x01
    bl2_stage_init 0xc1
    bl2_stage_init 0x02

    Doing a "reboot" or "shutdown -r now" as root leads to the following messages, compare the "hw id" line:

    [   95.523748] reboot: Restarting system
    bl31 reboot reason: 0xd
    bl31 reboot reason: 0x0
    system cmd  1.
    SM1:BL:511f6b:81ca2f;FEAT:A0F83180:20282000;POC:F;RCY:0;EMMC:800;NAND:81;SD?:0;SD:0;READ:0;0.0;CHK:0;
    bl2_stage_init 0x01
    bl2_stage_init 0x81
    hw id:øSM1:BL:511f6b:81ca2f;FEAT:A0F83180:20282000;POC:F;RCY:0;EMMC:800;NAND:81;SD?:0;SD:400;USB:8;

    The first "SM1" line is the same, no clue about the meanings of the status message, but "SD:0" seems to say "SDcard is fine", and booting starts. The next "bl2_stage_init" lines are identical, but while the "hw id" line is fine in the cold start, it is interrupted in the warm start (reset) by a SM1 line again, this time mit "SD:400" - which obviously is bad.

    I could figure out something so far:

    • SD:20000 -> no SDcard inserted
    • SD:0 -> SD card fine (?)
    • SD:400 -> our problem

    As this message occurs without any boot media, it must originate directly from the SoC.

    It doesn't originate from the power on reset (VDDIO_AO), this line is accessible on the UART header, no dip visible.

     

    I will dig deeper...

     

    Edit: my best guess so far is a forgotten watchdog timer which resets the system while it tries to reboot. For reasons unknown to me this seems not to hit when eMMC is booting. According to the data sheet the eMMC card is probed earlier then uSD, and this may already make a difference?

     


  6. Made some tests now with Armbian 20.05.2 and 4.9.224-odroidc4 - reboot works with uSD cards.

    For me it looks like a timing problem in Uboot... I will have to make some measurements on uSC pins to see if the problem can be seen there.

     

    Removing the uSD card after the first boot attempt and reinserting it doesn't help, power cycle is needed.


  7. 1 hour ago, Arpel said:

    Hi,

    My 2 cents here : I'm using Armbian on C4 since 14 days now and I only had reboot issue (on eMMC) with the early versions (5.4 kernel) : 5.6 never got stuck.

    Could you try with uSD cardf (while we both know that uSD is always second choice :)

    My system stucks very often with uSD while eMMC seems to work fine.


  8. I compiled a Buster system with new kernel (5.6.16)  now with the build system, and tested on eMMC card. Same results, reboot works fine on eMMC card.

     


  9. Hi Igor, eMMC reboot was 20x so far with no lockup.

    It seems a uSD card problem - I have not managed to get a "reboot" with uSD card done properly. I use a SanDisk Extreme 16GB Class 3 HC I card.

    The power supply should be sufficient (12V 2A).

    With uSD card, the following errors occur when I log in after booting and do a "reboot" as root:

    root@odroidc4:~# reboot
    [   59.522866] reboot: Restarting system
    bl31 reboot reason: 0xd
    bl31 reboot reason: 0x0
    system cmd  1.
    SM1:BL:511f6b:81ca2f;FEAT:A0F83180:20282000;POC:F;RCY:0;EMMC:800;NAND:81;SD?:0;SD:0;READ:0;0.0;CHK:0;
    bl2_stage_init 0x01
    bl2_stage_init 0x81
    hw id:øSM1:BL:511f6b:81ca2f;FEAT:A0F83180:20282000;POC:F;RCY:0;EMMC:800;NAND:81;SD?:0;SD:400;USB:8;LOOP:1;EMMC:800;NAND:81;SD?:0;SD:400;USB:8;

    After that, the system is stuck and needs a power cycle (didn't find a reset yet).

     

    The same image on an eMMC card does the following on a "reboot":

    root@odroidc4:~# reboot
    [   50.423833] reboot: Restarting system
    bl31 reboot reason: 0xd
    bl31 reboot reason: 0x0
    system cmd  1.
    SM1:BL:511f6b:81ca2f;FEAT:A0F83180:20282000;POC:F;RCY:0;EMMC:0;READ:0;0.0;CHK:0;
    bl2_stage_init 0x01
    bl2_stage_init 0x81
    hw id: 0x0000 - pwm id 0x01
    bl2_stage_init 0xc1
    bl2_stage_init 0x02
    
    L0:00000000
    L1:00000703
    L2:00008067
    L3:15000020
    S1:00000000
    B2:20282000
    B1:a0f83180
    
    TE: 67922
    
    BL2 Built : 20:29:41, Jun 18 2019. g12a ga659aac - luan.yuan@droid15-sz
    
    Board ID = 1
    Set cpu clk to 24M
    Set clk81 to 24M
    Use GP1_pll as DSU clk.
    DSU clk: 1200 Mhz
    CPU clk: 1200 MHz
    Set clk81 to 166.6M
    eMMC boot @ 0
    sw8 s

    So there are differences in the output, I have no clue yet where this output comes from.

    Hope this helps.

     

     

  10. Edited by mboehmer
    New information added


    Hm. I just did a loop of reboots on the download image (Armbian Focal with Linux 5.6.15-meson64), and had no stuck. I use an Hardkernel 16GB eMMC and a 2A 12V power supply.

    EDIT: I can't get a reboot problem reproduced with eMMC card. With uSD card, it happens very frequently (same image used). The reboot command either is the last message I get in the console, or we end up like that:

    [  262.787662] reboot: Restarting system
    bl31 reboot reason: 0xd
    bl31 reboot reason: 0x0
    system cmd  1.
    SM1:BL:511f6b:81ca2f;FEAT:A0F83180:20282000;POC:F;RCY:0;EMMC:800;NAND:81;SD?:0;SD:0;READ:0;0.0;CHK:0;
    bl2_stage_init 0x01
    bl2_stage_init 0x81
    hw id:øSM1:BL:511f6b:81ca2f;FEAT:A0F83180:20282000;POC:F;RCY:0;EMMC:800;NAND:81;SD?:0;SD:400;USB:8;LOOP:1;EMMC:800;NAND:81;SD?:0;SD:400;USB:8;

    It seems to me that the reboot problem only affects uSD operation.


  11. I have my C4 now, with eMMC card, and tried first the standard download image. Works nicely!

     

    I started compiling my own system, so I can assist in debugging - anything which I should start with?

     

     


  12. Hi,

     

    will join testing next week, my board is on the way. The C4 would have been a great choice for this year's deployment, the 4GB option would have helped.

    BTW, it's unclear for me, but does the C4 have a hardware SPI master in contrast to the C2 software SPI master?

     

    See you, Michael

     


  13. Solved, finally. A collegue of mine (ZSH fan :) made it working.

    Basically, the dbus_x11 was first part of problem, and the missing ZSH entry in the user crontab:

     

    SHELL=/usr/bin/zsh
    
    @reboot /usr/bin/zsh -l -c "LD_PRELOAD=/lib/aarch64-linux-gnu/libgcc_s.so.1 vncserver -localhost no"

     

    Now we are just "stuck" with the libunwind problem, but that can be worked around by PRELOAD for now.

    Somehow I'M a bit happy about the forced lockdown now, as it shifted deployment and allows us to solve some problems in a really good manner, and not under high time pressure :)


  14. Hi Linuxfan,

     

    your line doesn't work for me. We use ZSH on the system, and executing the /etc/profile gives us a working VNC server, but no ZSH anymore. Which in turn leads to malfunctioning of the startup of hardware... if you can give me a hint on how to source the correct environment, it would be great.

     

    See you, Michael


  15. Thanks for the information.

    At the moment, I'm happy with the rc.local solution, as it works :)

    I was in contact with Adrian Bunk, who is maintaining libunwind (and was at university with me), but didn't get any response so far.

     

    I will try the crontab solution as time permits, due to Corona we are delayed with deployment, and things might shift for at least six months :(


  16. I finally could find some suitable solution here.

    Basically it is like

     

      // System timer of ARMv8 runs at a different frequency than the CPU's.
      // The frequency is fixed, typically in the range 1-50MHz.  It can be
      // read at CNTFRQ special register.  We assume the OS has set up
      // the virtual timer properly.
      int64_t virtual_timer_value;
      asm volatile("mrs %0, cntvct_el0" : "=r"(virtual_timer_value));
      return virtual_timer_value;

    It seems to return meaningful values, just in case someone else needs some similar benchmarking.

     


  17. Hi all,

     

    I have some piece of software to compile on our Armbina system (Linux odroidc2 4.19.90-meson64 #5.99 SMP PREEMPT Fri Dec 20 13:47:25 CET 2019 aarch64 GNU/Linux).

    It is a C++ program, usually running on x86 machines, and has one line of code killing the compilation:

    asm volatile ("rdtsc" : "=a" (low), "=d" (high));

    I need to replace it by some code working with g++ on ARM64.

    Anyone how can give me a hint? I tried Google, but found no reasonable solution.

     

    In case, the software package is public, if you need the link to get it, please let me know.

     

    Any help is appreciated.

    Thanks in advance, Michael


  18. Dear community,

     

    unfortunately, "armbianmonitor -u" doesn't give me a link anymore, and I'm not sure if uploading works at all. So I cant provide the information :(

     

    As our deployment date approaches, we try to finalize our Armbian system for North Pacific seafloor... and found some unexpected problems (problems seem alwas to be unexpected):

    The TigerVNC has two problems on Armbian, and it would be great if you could verify that issues and maybe problem some helpful ideas:

     

    (1) TigerVNC (tigervnc-common/stable,now 1.9.0) needs the following workaround to start at all:

    LD_PRELOAD=/lib/aarch64-linux-gnu/libgcc_s.so.1 vncserver :1 -localhost no

       Seems to be libunwind8 related, and is ugly, but not the main problem.

     

    (2) TigerVNC can be started by crontab "@reboot", but fails to open a desktop. There are messages about dbus problems, the display closes afterwards.

     

    I use Armbian NEXT, with Debian Buster, and kernel is locked to 4.19.90 (due to the various troubles with the new kernel, which seems to be optimzed for video playback but not stable operation).

     

    Any help is appreciated, and if you need more information, please let me know.

     

    So far, Michael

     

     


  19. Hi,

     

    just to let you know, I changed from "next" to "current", and found some quirks in the "current" kernel (using "buster").

     

    (1) uart_C is not working (already fixed by martinayotte, thanks for the fast response!)

     

    (2) microSD card behaves strange: you can boot from uSD card, that works. When booting from eMMC card, the uSD clot is "dead", card insertation is not recognized anymore, it can't be used.

     

    Michael


  20. I will return for the time being to NEXT kernel, and add the necessary patches to device tree there.

    The MAC issue I think can be solved. Apparently the /usr/bin/armbian/armbian_firstrun takes the (by uBoot correctly set) MAC address and uses nmcli to fix it in software (which seems pretty useless for me, as it is stored in efuse anyhow in each board).

    Manually removing the "cloned-mac-address" line in NetworkManager config file (/etc/NetworkManager/system-connections/*) forces the eth0 to use the uBoot provided MAC again.

    Edit: I think this line

    # varios temporary hardware workarounds
    [[ $LINUXFAMILY == meson64 ]] && set_fixed_mac

    should be changed accordingly to not tinker with C2 MAC address anymore.