mboehmer

Members
  • Content Count

    110
  • Joined

  • Last visited

 Content Type 

Forums

Member Map

Store

Crowdfunding

Raffles

Applications

Calendar

Everything posted by mboehmer

  1. mboehmer

    Odroid C4

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

    Odroid C4

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

    Odroid C4

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

    Odroid C4

    As we know now where the uSD card problem resides, is there anyone working on that already?
  5. mboehmer

    Odroid C4

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

    Odroid C4

    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?
  7. mboehmer

    Odroid C4

    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.
  8. mboehmer

    Odroid C4

    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.
  9. mboehmer

    Odroid C4

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

    Odroid C4

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

    Odroid C4

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

    Odroid C4

    Which image should I test? downloadable one or self compiled?
  13. mboehmer

    Odroid C4

    OK, I asked for it, so I got it. Is reboot affected by uSD or eMMC?
  14. mboehmer

    Odroid C4

    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?
  15. mboehmer

    Odroid C4

    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
  16. 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 :)
  17. 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
  18. 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
  19. 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.
  20. 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
  21. 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
  22. Update: compiled a new image (Armbian_19.11.9_Odroidc2_buster_current_5.4.16), and this one is working again on C2 rev 0.2 201171114 - eth0 is online. uSD card also seems to work as expected.
  23. 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
  24. 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.
  25. It is very strange. Boards failing with dev kernel work with next kernel. The board rev is the only feature so far which seems to make a difference.