guidol
-
Posts
1798 -
Joined
-
Last visited
Content Type
Forums
Store
Crowdfunding
Applications
Events
Raffles
Community Map
Posts posted by guidol
-
-
That looks like a good start - but my "dream" is a PWM-controlled fan which will spin slowly/fast depending on the temperature.
I couldnt imagine that nobody before has built something like this.
The PWN controlled fan could be controlled by the SBC itself or by a small MCU like a arduino... -
Today my C2 is running fine (booted from MicroSD) and with working ethernet using the "bleeding edge" version of armbian buster
cd /usr/lib/linux-u-boot-edge-odroidc2_21.05.1_arm64 dd if=./bl1.bin.hardkernel of=/dev/mmcblk0 bs=1 count=442 conv=fsync > /dev/null 2>&1; dd if=./bl1.bin.hardkernel of=/dev/mmcblk0 bs=512 skip=1 seek=1 conv=fsync > /dev/null 2>&1; dd if=./u-boot.bin of=/dev/mmcblk0 bs=512 seek=97 conv=fsync > /dev/null 2>&1 dd if=/dev/mmcblk0 of=/tmp/installed_uboot.bin skip=97 count=1376 strings /tmp/installed_uboot.bin | grep "U-Boot 20" U-Boot 2021.04-armbian (May 06 2021 - 18:07:48 +0000) odroid-c2 ___ _ _ _ ____ ____ / _ \ __| |_ __ ___ (_) __| | / ___|___ \ | | | |/ _` | '__/ _ \| |/ _` | | | __) | | |_| | (_| | | | (_) | | (_| | | |___ / __/ \___/ \__,_|_| \___/|_|\__,_| \____|_____| Welcome to Armbian 21.05.2 Buster with bleeding edge Linux 5.12.6-meson64 package bsp-kernel[21.05.2] u-boot[21.05.1] dtb [21.05.2] firmware [21.05.2] config[21.05.3] branch[edge] dmesg |grep -i ether [ 1.757833] igb: Intel(R) Gigabit Ethernet Network Driver [ 2.235419] meson8b-dwmac c9410000.ethernet: IRQ eth_wake_irq not found [ 2.235437] meson8b-dwmac c9410000.ethernet: IRQ eth_lpi not found [ 2.235529] meson8b-dwmac c9410000.ethernet: PTP uses main clock [ 2.244419] meson8b-dwmac c9410000.ethernet: User ID: 0x11, Synopsys ID: 0x37 [ 2.244444] meson8b-dwmac c9410000.ethernet: DWMAC1000 [ 2.244451] meson8b-dwmac c9410000.ethernet: DMA HW capability register supported [ 2.244456] meson8b-dwmac c9410000.ethernet: RX Checksum Offload Engine supported [ 2.244461] meson8b-dwmac c9410000.ethernet: COE Type 2 [ 2.244466] meson8b-dwmac c9410000.ethernet: TX Checksum insertion supported [ 2.244471] meson8b-dwmac c9410000.ethernet: Wake-Up On Lan supported [ 2.244556] meson8b-dwmac c9410000.ethernet: Normal descriptors [ 2.244562] meson8b-dwmac c9410000.ethernet: Ring mode enabled [ 2.244567] meson8b-dwmac c9410000.ethernet: Enable RX Mitigation via HW Watchdog Timer [ 5.120227] meson8b-dwmac c9410000.ethernet eth0: PHY [stmmac-0:00] driver [RTL8211F Gigabit Ethernet] (irq=46) [ 5.134367] meson8b-dwmac c9410000.ethernet eth0: No Safety Features support found [ 5.134391] meson8b-dwmac c9410000.ethernet eth0: PTP not supported by HW [ 5.134734] meson8b-dwmac c9410000.ethernet eth0: configuring for phy/rgmii link mode [ 6.791266] meson8b-dwmac c9410000.ethernet eth0: Link is Up - 100Mbps/Full - flow control rx/tx
-
4 hours ago, whitefeather said:
At this point I wondered if the problem is somwehere with the drivers, I tried both the OrangePI provided images (Debian and Ubuntu) and the Armbian images that the user guidol (thank you, you did a great job!) managed to compile a couple of years ago, but nothing changes.
Is anyone using succesfully this board with a high-speed (2.0) device??
Thanks for the "flowers", but I only compiled the image when the option was available in the armbian-build-system.
The Preconfiguration wasnt done by me
On my i96 I never did the USB port to work, because it seems that it was allways "underpowered" - also with a bigger power supply and not using the MicroUSB-port.
Also there was no kernel-module working for USB-Audio
I also didnt like the high baudrate at the TTL-serial-port which did work very flaky for me
-
use date like date MMDDhhmmCCYY
MM Monthnumber
DD Daynumber
hh hours
mm minutes
CC Century
YY Year
date 052211382021
for 05/22/2021 11:38
-
Why not using a arm64 devuan image for a arm63 Server?
-
On 4/13/2021 at 11:12 PM, cracker said:
No network,so cant install anything.
a USB-ethernet adapter will help you to get a Network connection
-
you could try the socat command which supports some raw-configuration.
I use it to "copy" the stream from /dev/ttyUSB0 to /dev/ttyUSB1 for connecting 2 USB-serial devices on a armbian-SBC
-
1 hour ago, Dante Alighieri said:
Why bother with this garbage? Get a proper machine with PROPER software instead of this waste of time
because we can
If you dont like other SBCs like the RPi (I did read all your content on this forum) then do ua a favour and use only RPI-SBCs.
If you also could see we didnt support here the RPi.
If you want to help us its OK, but only to tell that we use "garbage" SBCs isnt helpful. And many here can use this "garbage" very well andthey arent a copy, because they use very different hardware.
If they were a cop they could use the "great Raspbian".
But for us armbian is mostly better. The Raspberry and Raspbian has a much wider user-base and more support from companys - thats right, but alsothey doesnt do all things right ans so for some soultion a alternativ SBC and OS is better for some of us.
-
2 hours ago, Igor said:
Manual way: removing current -dev armbian packages and install -edge variants. But stable base doesn't have u-boot packages ...
@Igor I replaced (by the meaning of u-boot)
linux-u-boot-nanopineo2-devwith
linux-u-boot-nanopineo2-edge ( linux-u-boot-edge-nanopineo2_21.05.0-trunk_arm64.deb )
But Iam searching for the -edge replacement for linux-buster-root-dev-nanopineo2, because apt has only for "linux edge":
[EDIT] this was created at./output/debs/buster/linux-buster-root-edge-nanopineo2_21.05.0-trunk_arm64.deb
Did edit the instructions above
-
maybe a stupid little question
Is there an "official" way to update kernel-package from dev to edge without recompiling/installing the newest image?
I did manually for one of my NanoPi Neo2:
apt remove linux-u-boot-nanopineo2-dev -y apt remove linux-dtb-dev-sunxi64 -y apt remove linux-image-dev-sunxi64 -y apt remove linux-buster-root-dev-nanopineo2 -y dpkg -i ./linux-u-boot-edge-nanopineo2_21.05.0-trunk_arm64.deb dpkg -i ./linux-buster-root-edge-nanopineo2_21.05.0-trunk_arm64.deb dpkg -i ./linux-dtb-edge-sunxi64_21.05.0-trunk_arm64.deb dpkg -i ./linux-image-edge-sunxi64_21.05.0-trunk_arm64.deb dpkg -i ./armbian-zsh_21.05.0-trunk_all.deb dpkg -i ./armbian-firmware_21.05.0-trunk_all.deb dpkg -i ./armbian-config_21.05.0-trunk_all.deb
_ _ ____ _ _ _ ____ | \ | | _ \(_) | \ | | ___ ___ |___ \ | \| | |_) | | | \| |/ _ \/ _ \ __) | | |\ | __/| | | |\ | __/ (_) | / __/ |_| \_|_| |_| |_| \_|\___|\___/ |_____| Welcome to Armbian 21.05.0-trunk Buster with bleeding edge Linux 5.11.11-sunxi64 No end-user support: built from trunk package bsp-kernel[21.05.0-trunk] u-boot[21.05.0-trunk] dtb [21.05.0-trunk] firmware [21.05.0-trunk] config[21.05.0-trunk] branch[edge]
System diagnosis information has been uploaded to http://ix.io/2UJG
-
6 hours ago, IgorS said:
Hello Armbian,
Since long time ago, build system is stuck at mainline kernel version 5.10.21 (for OrangePi H2+ H3 and H5 boards).
Am I doing something wrong or what?
Do you generate - with the build system - only "current"-images?
Because in DEV for H2+/H3 I got 5.11.2 on the NanoPi Neo (sunxi):
5.11.2-sunxi #trunk SMP Tue Mar 2 18:14:30 +03 2021 armv7l GNU/Linuxand 5.11.3 at he H5 CPU with a NanoPi Neo2 (sunxi64):
5.11.3-sunxi64 #trunk SMP Mon Mar 8 23:00:36 +03 2021 aarch64 aarch64 aarch64 GNU/Linux -
If you want to use a "real" Terminal - instead of SSH / Ser2Net- like the TTGO VGA32 FabGL ANSI-Terminal and you dont have a 3.3V <-> 5.0V logic level converter available then using the NanoPi K1 Plus (or any other armbian device with 2 USB-ports) as a "mediator" may be possible using the "socat"-command
To use socat we should disable (disable for every boot or stop until the next boot) the ser2net service:
Usage: /etc/init.d/ser2net {start|stop|restart|reload|force-reload|status} sudo service ser2net restart sudo service ser2net stop sudo service ser2net start sudo systemctl disable ser2net sudo systemctl enable ser2netWe do connect 2 USB-TTL-serial-Adapters to the SBC (one for 3.3V TTL-Level and one for 5V TTL-Level).
Via software (socat = apt install socat) we tie them together:
socat /dev/ttyUSB0,raw,echo=0,crnl,b115200 /dev/ttyUSB1,raw,echo=0,crnl,b115200
For the correct backspace-function the FabGL-ANSI-Terminal has to be in "ANSI Legacy"-Mode, because in normal "ANSI"-Mode the backspace-key doenst work right with the output of the Z80-MBC2
-
The Z80-MBC2 is a 4-chip Z80-computer which can run CP/M and has a 5V TTL-serial-port.
The Z80-MBC2 is powered and accessable via a USB-TTL-serial-adapter (configured to 5V - not 3.3V) type CP2102 seen as /dev/ttyUSB0The easy way would be to connect the USB-adapter to a Pi-style computer wth armbian, login via SSH and start minicom for the port.
But that way doenst look as good - to me - as the following way
First we need to install ser2net and telnet (telnet doesnt seem to be installed as standard) in armbian via
apt install ser2net telnet
Then we have to edit /etc/ser2net.conf (delete all lines after the comments and insert these):
BANNER:banner:\r\nser2net port \p device \d [\s] (Debian GNU/Linux)\r\n\r\n BANNER:z80mbc2:\r\nZ80-MBC2 via Telnet on Port [\p]\r\nDevice connected to [\d]\r\nConnection Speed [\s]\r\n # 2000:telnet:600:/dev/ttyS0:9600 8DATABITS NONE 1STOPBIT banner # 2001:telnet:600:/dev/ttyS1:9600 8DATABITS NONE 1STOPBIT banner # 3000:telnet:600:/dev/ttyS0:19200 8DATABITS NONE 1STOPBIT banner # 3001:telnet:600:/dev/ttyS1:19200 8DATABITS NONE 1STOPBIT banner 127.0.0.1,2023:telnet:0:/dev/ttyUSB0:115200 8DATABITS NONE 1STOPBIT z80mbc2
Now create a login "shell"/pogram for the new local user z80mbc2 as /usr/local/bin/z80mbc2 :
#!/bin/sh /usr/bin/telnet 127.0.0.1 2023 exitDo a chmod 755 /usr/local/bin/z80mbc2
Now we can create the new local user z80mbc2 as seen on
http://www.lug-wr.de/wiki/index.php/Howto:Network:SerialConsoleServer
adduser --shell /usr/local/bin/z80mbc2.sh -q z80mbc2If you havent done - connect your TTL-USB-Dongle to your SBC - and it should show up as /dev/ttyUSB0 :
[354660.047087] usb 7-1: Product: CP2102 USB to UART Bridge Controller [354660.047099] usb 7-1: Manufacturer: Silicon Labs [354660.047109] usb 7-1: SerialNumber: 0001 [354660.112318] usbcore: registered new interface driver usbserial_generic [354660.112414] usbserial: USB Serial support registered for generic [354660.131499] usbcore: registered new interface driver cp210x [354660.131617] usbserial: USB Serial support registered for cp210x [354660.131902] cp210x 7-1:1.0: cp210x converter detected [354660.141405] usb 7-1: cp210x converter now attached to ttyUSB0
Now its time to reboot your SBC (I used my NanoPi K1 Plus) via
rebootto automatically let start ser2net-service while booting
Now when you connect to your SBC via SSH and use the z80mbc2 User to login, you should generate a automatic and local (127.0.0.1) telnet-login to Port 2023 where /dev/ttyUSB0 a.k.a the Z80-MBC2 device is configured.
PS: other (german) interesting Page about ser2net:
http://www.nwlab.net/tutorials/ser2net/konsolenserver-linux.html
-
7 hours ago, malaga said:I need a Operating-System for
- Alwinner /banana Pi A 20
- Udoo Quad Makerboard Rev. D.
- Orange PI Prime rev 1.0find at https://www.armbian.com/download/ all downloads
- Alwinner /banana Pi A 20
https://redirect.armbian.com/bananapi/Buster_current
- Udoo Quad Makerboard Rev. D.https://redirect.armbian.com/udoo/Buster_current
- Orange PI Prime rev 1.0https://redirect.armbian.com/orangepiprime/Buster_current_xfce
-
14 hours ago, 9acca9 said:
I plan to use Stockfish, but it turns out that the "pc" where I am mounting everything is a raspberry pi zero w ... and the truth is that it is very slow
will you have any information on how to put stockfish as a server in windows 10?
(or maybe how run stockfish with better results on a rpi zero.
@9acca9 No wonder
the RPi Zero is only a Single-Core SBC with max. 1GHz.
OK - this sounds much for a normal chess-computer, but not for stockfish. You also get what you paid for
You did better buy something like a Orange Pi Zero ( a chep QuadCore SBC).
I dont know (az this time) how to setup a Win10-Chess Server, because stockfish for Windows is only a commandline program and I dont know how to connect it externally via TCP or serial.
All Windows GUI Chess programs can use the command-line UCI connection to use stockfish ( https://stockfishchess.org/download/windows/ ) -
6 hours ago, Werner said:
Never heard of etcher.net. Maybe scam?
Make sure you grab the tool from https://www.balena.io/etcher/
QuoteDO NOT download etcher from etcher.NET!
I made this mistake while going from windows 10 to pop os. If you're going to use etcher (balena etcher) to flash a usb go to [balena.io/etcher/]. This is their real site! etcher.NET gives you nothing but a bogus installer that tries to get you to install several unwanted software, before proceeding to NOT install etcher. This is what I get for trying Bing, which recommended this above the legitimate site.
-
where did you get the .deb for the linux-image (5.10.21-meson64)?
Why didnt you used armbian-config (System -> Other -> Switch to other Kernel) to change the kernel/image?
When you did selfcompile the image via armbian-build-system....did you try to update the packages like u-boot, firmware and so on before the linux-image?
-
1 hour ago, Elclaudio said:
@guidol : it's possible, while, I'm not sure of it, that it work for you because you're on a 100Mbps link ?
I've heard some reports that eth0 used to work on 100M but not on 1G in the past.
Or it could be the environnement, connected usb device at boot, power supply.
I don't recall also if your using an emmc or an sdcard ?
@Elclaudio I have only power (Single-USB-Power 5V/1A from an old "Palm"-Power-Supply (PSU 157-10108-00))
and ethernet (100MBit) connected.
For you
I switched a short time my C2 to the 1GBit-Switch rebooted/tested - works also:
[87945.551990] meson8b-dwmac c9410000.ethernet eth0: Link is Down [87967.818374] meson8b-dwmac c9410000.ethernet eth0: Link is Up - 100Mbps/Full - flow control off [88095.093734] meson8b-dwmac c9410000.ethernet eth0: Link is Down [88097.665953] meson8b-dwmac c9410000.ethernet eth0: Link is Up - 1Gbps/Full - flow control off root@odroid-c2-3(192.168.6.3):~# reboot [ 2.190284] meson8b-dwmac c9410000.ethernet: IRQ eth_wake_irq not found [ 2.190304] meson8b-dwmac c9410000.ethernet: IRQ eth_lpi not found [ 2.190399] meson8b-dwmac c9410000.ethernet: PTP uses main clock [ 2.193291] meson8b-dwmac c9410000.ethernet: User ID: 0x11, Synopsys ID: 0x37 [ 2.193319] meson8b-dwmac c9410000.ethernet: DWMAC1000 [ 2.193326] meson8b-dwmac c9410000.ethernet: DMA HW capability register supported [ 2.193331] meson8b-dwmac c9410000.ethernet: RX Checksum Offload Engine supported [ 2.193336] meson8b-dwmac c9410000.ethernet: COE Type 2 [ 2.193340] meson8b-dwmac c9410000.ethernet: TX Checksum insertion supported [ 2.193345] meson8b-dwmac c9410000.ethernet: Wake-Up On Lan supported [ 2.193683] meson8b-dwmac c9410000.ethernet: Normal descriptors [ 2.193695] meson8b-dwmac c9410000.ethernet: Ring mode enabled [ 2.193700] meson8b-dwmac c9410000.ethernet: Enable RX Mitigation via HW Watchdog Timer [ 6.964191] meson8b-dwmac c9410000.ethernet eth0: PHY [stmmac-0:00] driver [RTL8211F Gigabit Ethernet] (irq=46) [ 6.968309] meson8b-dwmac c9410000.ethernet eth0: No Safety Features support found [ 6.968332] meson8b-dwmac c9410000.ethernet eth0: PTP not supported by HW [ 6.968697] meson8b-dwmac c9410000.ethernet eth0: configuring for phy/rgmii link mode [ 10.263501] meson8b-dwmac c9410000.ethernet eth0: Link is Up - 1Gbps/Full - flow control rx/tx
On some GBit devices I use sometimes the ethtool to set speed to 100MBit but the C2 does it right on a 100MBit-Port:
.# /etc/rc.local
# for a 100MBit device - comment out for 1GBit
# ethtool -s eth0 speed 100 autoneg offHere is the reboot with 1GBit on eth0 of my C2 (5-Port DLINK GBIt Switch):
System diagnosis information has been uploaded to http://ix.io/2Sh8 -
Only Orange Pi Zero Revision 1.5 (printed on the mainboard) is a LTS-version and should run cooler
-
My C2 did already work/reboot with
U-Boot 2021.01-armbian (Mar 03 2021 - 14:32:21 +0300) odroid-c2
But today I compiled the new u-boot
U-Boot 2021.04-rc3-armbian (Mar 08 2021 - 18:12:26 +0300) odroid-c2
which does also work/reboot fine on my C2
System diagnosis information has been uploaded to http://ix.io/2SaS
[EDIT]
does also work with newer dev-kernel
FROM Linux 5.10.19-meson64 TO Linux 5.11.4-meson64
System diagnosis information has been uploaded to http://ix.io/2SaU
# dd if=/dev/mmcblk0 of=/tmp/installed_uboot.bin skip=97 count=1376 1376+0 Datensätze ein 1376+0 Datensätze aus 704512 bytes (705 kB, 688 KiB) copied, 0,0525366 s, 13,4 MB/s # strings /tmp/installed_uboot.bin | grep "U-Boot 20" U-Boot 2021.01-armbian (Mar 03 2021 - 14:32:21 +0300) odroid-c2 # dpkg -i ./linux-u-boot-dev-odroidc2_21.05.0-trunk_arm64.deb cd /usr/lib/linux-u-boot-dev-odroidc2_21.05.0-trunk_arm64 dd if=./bl1.bin.hardkernel of=/dev/mmcblk0 bs=1 count=442 conv=fsync > /dev/null 2>&1; dd if=./bl1.bin.hardkernel of=/dev/mmcblk0 bs=512 skip=1 seek=1 conv=fsync > /dev/null 2>&1; dd if=./u-boot.bin of=/dev/mmcblk0 bs=512 seek=97 conv=fsync > /dev/null 2>&1 [reboot] # dd if=/dev/mmcblk0 of=/tmp/installed_uboot.bin skip=97 count=1376 1376+0 Datensätze ein 1376+0 Datensätze aus 704512 bytes (705 kB, 688 KiB) copied, 0,04659 s, 15,1 MB/s # strings /tmp/installed_uboot.bin | grep "U-Boot 20" U-Boot 2021.04-rc3-armbian (Mar 08 2021 - 18:12:26 +0300) odroid-c2
-
@Igor just one more "repaired" patient
After getting at Tuesday the NanoPi Neo working fine with his eth0 - I did gave my Orange Pi R1 a new "ride" today.The last months (or year) I did think his eth0 is defective, because when ethernet there is inserted the orange-led blinks only on/off and isnt accessable when the Orange Pi R1 is booted. I could only use the second ethernet port (WITH THE SAME cable) which is onboard conected via USB (enx-device)
Today I put him on the same 1st 2x4 ports of my 16 port 100MBit Hub - and the blinking orange led stays on and does work as eth0
System diagnosis information has been uploaded to http://ix.io/2RUJ
Because I have no more feee ports I had to move another system from the 1st to the 2nd part of the Ethernet-Switch.
So also the Orange Pi R1 - like the NanoPi Neo - seems to have a difference on their eth0-port (phy?) against other systems.
Strange for me was that the 2nd onboard-USB-connected Ethernet-port did work on the same Ethernet-cable (and Switch-Port), but not on the onboard chipset-included eth0.
So in the past we took that as some "Voodoo" and many other people with other Ethernet-Switches.
The "solution" of @Adrian Cable should be tested in future by such network problems
-
Some "strange" behaviour:
I compiled a fresh dev-version, which has u-boot "U-Boot 2021.01-armbian (Mar 03 2021 - 14:32:21 +0300) odroid-c2"
and flashed it on a new sdcard:
___ _ _ _ ____ ____ / _ \ __| |_ __ ___ (_) __| | / ___|___ \ | | | |/ _` | '__/ _ \| |/ _` | | | __) | | |_| | (_| | | | (_) | | (_| | | |___ / __/ \___/ \__,_|_| \___/|_|\__,_| \____|_____| Welcome to Armbian 21.05.0-trunk Buster with Linux 5.10.19-meson64 No end-user support: built from trunk package bsp-kernel[21.05.0-trunk] u-boot[21.05.0-trunk] dtb [21.05.0-trunk] firmware [21.05.0-trunk] config[21.05.0-trunk] branch[dev] System load: 36% Up time: 1 min Memory usage: 5% of 1.85G IP: 192.168.6.3 CPU temp: 45°C Usage of /: 5% of 30G root@odroid-c2-3 : /home/guido# dd if=/dev/mmcblk0 of=./installed_uboot.bin skip=97 count=1376 1376+0 Datensätze ein 1376+0 Datensätze aus 704512 bytes (705 kB, 688 KiB) copied, 0,0871237 s, 8,1 MB/s root@odroid-c2-3 : /home/guido# strings ./installed_uboot.bin | grep "U-Boot 20" U-Boot 2021.01-armbian (Mar 03 2021 - 14:32:21 +0300) odroid-c2
at the first boot it did boot normally. I did some changes/updated and rebooted and got this problem with eth0 like some here.
So I think I was prepared and copied with another NanoPi the old u-boot in my home-directory on the card for flashing it to mmcblk0.
I did expect to see the same eth0-problem on the 3rd boot, but now it does work again with the new u-boot.
OK - not every reboot does reboot, but after pulling the power-plug - waiting 5 seconds an reconnect the power the C2 does boot here with the new u-boot like with the old u-boot of 2019 (armbian 5.77)
I dont know if there much difference between current and dev u-boot or kernel, but for me it seems to work with the dev-version.
Maybe a little bit tricky, but OK for a dev-version.
I will attach here the actual dev-u-boot files for compare/test - maybe they are different to current?Also a boot-system-Info: uploaded to http://ix.io/2RzH
-
@Elclaudio @Igor for your and my security here is the u-boot
U-Boot 2019.01-armbian (Mar 25 2019 - 18:08:02 +0300) odroid-c2
root@npi-neo2-24(192.168.6.24):/mnt/sdb1/usr/lib/linux-u-boot-dev-odroidc2_5.77_arm64# strings ./u-boot.bin | grep 'U-Boot 20' U-Boot 2019.01-armbian (Mar 25 2019 - 18:08:02 +0300) odroid-c2out of my archive Armbian_5.77_Odroidc2_Debian_stretch_dev_5.0.4.img.zip
(isnt armbian 5.95, but near/close for the u-boot
)
This u-boot is currently installed/working on my C2 in mmcblk0
So if we want to test a newer version we can go back to a surely working ethernet-version
(which should be newwer than from your kernel 4.19)
-
11 hours ago, Elclaudio said:
Backup the current u-boot: (md5 checked against original u-boot.bin file match) the count value my be different on yours
And check it's version :
Indeed if you have a 2019.xx version you are ok apparently
Yes its seems also like a 2019-version (didnt changed the count - becaus it isnt a backup - only to get version:
root@odroid-c2 : /home/guido# dd if=/dev/mmcblk0 of=./installed_uboot.bin skip=97 count=1376 1376+0 records in 1376+0 records out 704512 bytes (705 kB, 688 KiB) copied, 0.0463896 s, 15.2 MB/s root@odroid-c2 : /home/guido# strings ./installed_uboot.bin | grep "U-Boot 20" U-Boot 2019.10-armbian (Dec 01 2019 - 09:31:42 +0300) odroid-c2
lightdm crashes after recent upgrade
in Pine RockPro64
Posted
@Igor I also got lightdm-problems while installing my Ordroid C2 from scratch
(2 times once with current and once with edge)
After trying different soutions from the net it didnt worked....BUT with a simple "enable Desktop" from armbian-config -> System-settings and the desktop did start again without any problems