raschid

OK, so the BPi M1 is still alive - after 6 days of this full-load zombie state. Two more M1s are currently joining it to test stability: BPi M1 #1: Armbian 5.38 - kernel 4.11.5 BPi M1 #2: same Armbian version - kernel 4.14.18 BPi M1 #3: Armbian 5.45 - kernel 4.17.0 rc7 (to see if stabilty improves) I will post results ...

I have the same issue on a BananaPi M1 with an attached SATA disk. It is running SAMBA, a media server, an iperf server, it monitors and log weather data from an attached weather station and does some home automation. "Freeze" means the system is becoming unresponsive to ssh, cron etc. while still responding to ping and the the reset button. A cpu-load triggered system LED remains solid on. The system ran completely stable on Bananian for nearly three years until I switched to armbian in January. Initially the freezes occured quite infrequently with the systmem running ok for weeks. I installed a daemon to monitor system load and dump "ps aux" is load exceeds 2 - but that never happens: The system becomes unresponsive before the daemon can kick in. After upgrading last Saturday it froze after just 22 hours. I am travelling right now - it's quite unsettling to think of the little bugger running at max overload for the next 5 days. I will downgrade as soon as I am back as @theprosuggests. TL;DR: Current armbians builds on A20 platforms seem to be unstable and have been for some time. Upgrading the current builds seems to make things worse.

Building a dev-kernel currently seems to fail to produce something like "linux-dtb-dev-sunxi_5.41_armhf.deb" in /build/output/debs/ Any idea why?

Correct. These discussions refer to rev 1.0 - the schematic details the new rev 1.1. The new version allows to power the SoC with 1.1V or 1.3V (for higher CPU frequencies) by changing the state of GPIO L6. AFAIK armbian currently does not support the new revision.

@IgorNot quite sure but several of these unresolved patches fail in compilation because they seem to expect an other (newer?) version of sunxi-h3-h5.dtsi - the current version lacks nodes thats pervious versions had (de, mixer0, tcon0, mmc2 hdmi amd hdmi-phy).

Question: How would Alpha, Beta, Stable map to kernel.org naming? Alpha = latest release candidate? Beta = stable? Stable = LTS?

build/cache/sources it gets populated once you start compilation ...

Yes, @sebastien, you will need a 3.3V-to-TTL level converter, e.g. MAX3232.

Ahhh, interesting. There is a difference between your (black) 1.1 PCBs and the (red) 1.3 ones most people seem to have: The internal storage is NAND and not eMMC. At least the chip on you pics is a NAND chip (this one here: https://media.digikey.com/pdf/Data Sheets/Micron Technology Inc PDFs/MT29FxG08xAA.pdf). I don't think armbian supports installing to NAND at this time. Sorry.

So in armbian-config / Systen settings / Install "Install to SATA, eMMC, NAND or USB" you hit OK and did not get the option: "1 Boot from eMMC - system on eMMC"? Can you post the output of lsblk to check that the OS "sees" the eMMC? That should look something like this: test@sunvell:~$ lsblk NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT mmcblk0 179:0 0 29.7G 0 disk └─mmcblk0p1 179:1 0 29.4G 0 part / mmcblk1 179:8 0 7.3G 0 disk └─mmcblk1p1 179:9 0 7.2G 0 part mmcblk1boot0 179:16 0 4M 1 disk mmcblk1boot1 179:24 0 4M 1 disk

Did you build your kernel with the armbian build system? Like this: # git clone --depth 1 https://github.com/armbian/build # cd build # ./compile.sh BOARD=sunvell-r69 Use the <NEXT> kernel. There have been changes recently to DRAM timing which have increased stability. To transfer the OS from SD-Card to eMMC use $sudo armbian-config. There is an option in the "Systems"-menu to transfer the OS to the internal eMMC.

Time CPU load %cpu %sys %usr %nice %io %irq CPU C.St. 17:17:45: 1008MHz 0.11 7% 4% 3% 0% 0% 0% 36.2°C 0/7 same build (4.14.20-sunxi). Ambient temp: 21 degs.

what exactly do you mean by "headless" - the default config for the armbian build system gives you hdmi support? Did you change the max cpu frequency (should not exceed 1008 kHz)? My R69s rarely exceed 40 degs ...

There's a typo in my code above - it should say &usb_otg, not &usb_org (thick fingers, sorry!): &usb_otg { dr_mode = "host"; status = "okay"; }; Did you catch that? If not, maybe give at another go with the above modification. This tag corresponds to the following part of the friendlyelec "all-in-one" dts: usb@01c19000 { compatible = "allwinner,sun8i-h3-musb"; reg = <0x1c19000 0x400>; clocks = <0x4 0x20>; resets = <0x4 0x11>; interrupts = <0x0 0x47 0x4>; interrupt-names = "mc"; phys = <0x1c 0x0>; phy-names = "usb"; extcon = <0x1c 0x0>; status = "okay"; dr_mode = "otg"; }; Based on that I would try exchanging "host" for "otg" in the dr_mode tag.

nope, same thing.

This is not necessary anymore (and not recommended). This now builds a kernel with the adapted DRAM clock freq.: # git clone --depth 1 https://github.com/armbian/build # cd build # ./compile.sh BOARD=sunvell-r69

Here's a link to the headless version: https://drive.google.com/file/d/1oGjWHzDMU7bfB_ywpG4Lods3Gva7KVcI/view?usp=sharing u need desktop?

Good news but still odd: the legacy image's FEX file indicates a DRAM clock of 576MHz. Never mind, I created a pull request with an updated u-boot patch which should solve the issue for other users as well. Thx for raising the issue and the extensive testing

@guidol I don't think this is an etcher issue - there may not be anything wrong with SD cards (for once). Could you connect via console and post the output for a hanging boot?

@guidol: Does the boot-stability improve, when you replace build/patch/u-boot/u-boot-sunxi/add-sunvell-r69.patch with the attached file (reduces DRAM clck to 408)? If stability improves, could you copy the OS to eMMC via armbian-config and check boot-stability? add-sunvell-r69.patch

new 4.14.17-next/stretch build has booted several times without a hitch (using a 32G SANdisk ULTRA btw.) ... more testing ...

OK, I am building an image with a 408MHz DRAM clk ... let's see ... you could try to change the following def-config line: CONFIG_DRAM_CLK=408 The current setting is 576MHz which seems to work without problems with legacy builds.

Yes. Yes. Sometimes the device seems to hang on first boot. Disconnecting and reconnectig power works. I have upgraded to 4.14.17 via deb-upgrade. I will try a clean install tomorrow.

Mainline kernel vers. 4.14.17 also works quite well (supporting eth, wifi, both usb-ports, emmc, ir, audio, ...). You could build it yourself with the armbian build system (https://docs.armbian.com/Developer-Guide_Build-Preparation/) # git clone --depth 1 https://github.com/armbian/build # cd build # ./compile.sh BOARD=sunvell-r69 for media stuff you better stay with the legacy kernel though ...

Very good. The xradio-driver on boards with the xr819-chip seem to work as well with 4.14.17 noe - tested: sunvell r69 and nanopi duo.