mboehmer

"Stable" stuff. I have seen worse things on commercial boards. How can I extract the DTB?

Hi, I'm using Windows Just kidding, no. The web editor here lured me to follow its "drag your file here"

I tried to re-upload by drag'n'drop, and again it is empty. Something doesn't like it.

rk3288.txtHi all, I stumbled across a board which may be of interest for one of my next projects. Here you can find a link to it, it is model JLD076 I have the board already on my desk, and as it is really well equipped with loads of interfaces, I would love to get Armbian working on it. J have attached the boot log from console to the message, it uses Uboot 2017, and seems to be based on a standard Rockchip eval board. Onboard peripherials are handled by the usual suspects: ethernet by RTL8211, WiFi by RTL8732, and some of the display links by ALC6540. eMMC is fixed on the baord, so RKUSB is needed (can be invoked by Uboot command or button). The only unusual part is an "ACTIVE 88460" which seems to handle the powerup sequencing and includes some DC/DC converters. So if one of the current Rockchip users or developpers can give me a hint which image to try (or to compile) it would be great. I posted in this groups, as I think that this board might be *very* similar to existing RK3288 boards. I'm in contact with the manufacturer to get some more detailed information, if needed. Thanks in advance, Michael

Hi all, as a small status update on the seafloor business, here are some pictures of the new Odroid C2 based instruments which will be deployed in September/October in the northers Pacific. Ten modules with different functionality will be deployed, all based on a standard setup of Odroid C2, TRB3sc FPGA based TDC DAQ system, one PADIWA preamp, and a modded mdedia converter serving as a fully configurable mini switch. One of the modules carries several Hamamatsu mini spectrometers, as well as a camera, to observe bioluminescence. Another module is targeting at muon tracking with SiPM based readout: I have some more picture of the more "fancy" PMT based modules, but don't want to flood this forum now with too many pictures. To all of you: thanks for the support you gave us over the last year, and the discussions on specific topics! Deployment pictures will follow once the modules are in place on the seafloor, 2600m deep in the Pacific (and operational, hopefully, this time we just have a GbE fiber, no serial port...) See you, Michael

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.

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

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.

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

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?

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?

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.

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.

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.

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.

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.

Which image should I test? downloadable one or self compiled?

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

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?

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

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 :)

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

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

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.

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