guidol

as a normal armbian-image it should be root as user and 1234 as initial password

Hello all,
 
I bought one of these nice little devices, and and after a week of playing with it, I'm quite satisfied. Of course the software side is not the best, but the board itself is powerful, cheap, and it is full of features.
 
Right now all I am missing is a working LCD under Linux. I bought the official phone display from Aliexpress, it works under Android, but no success so far in Linux. So I'm looking for some help here with it.
 
I have cleaned and formatted the kernel source code (kernel/drivers/video/rda directory), it uses and registers the ILI9806g_mcu according to the dmesg output, but there is only garbage on the screen after it is initialized. So I think the FrameBuffer driver maps to a wrong RAM address. The rda-fb module outputs this: "rda-fb rda-fb: init done, 480 x 800 = 1540096, at cf028000, phys 0x8e200000"
When I convert the 0x8e200000 to decimal, it is an insanely high number (around 2 terabytes), which is suspicious.
 
Is there anyone here with kernel and LCD programming experience, who could help me with sorting this out?

I also tried to compile a kernel from the released Android source code, which is a bit different, but it doesn't work either. My next project is to make working the Vivante driver, also found in the Android source.

If you have time and a spare Allwinner H3-CPU system (like the Orange Pi One or PC (not PC2 because of H3 CPU)
you could try the BASIC Engine NG for H3-PiComputers/Boards.
 
The - bare metall - BASIC seems to have very powerful commands - see the Online-Manual
 
A forum in BETA state is at this URL
 
I downloaded and booted the SDCard-Image from the 14.10.2021 (compressed size 5.4MB) from this directory
Image was written with Balena Etcher to the SDCard
 
Have fun and write new BASIC-programms!  
 

 

 

Thanks! lsmod / blacklist the modules resolves the issue.

Thank-you everyone. I would mark multiple solutions, but the board only allows me to mark one.

I got it working. Used the cron @reboot method on user root.  The LEDs are useful where on the screen it may look like it's got stuck, the LEDs will at least show if there is some activity and if the SOC is still got a heartbeat.  I'm still a noob on the higher technical issues of Linux.  I have one more question to ask and that will be in another thread.    (Yes, I will donate!  I've seen the donate link on the Armbian home page, but as you all know, the budget that keeps the roof over the head, electricity supplied, food on the table, etc... is priority. Shall donate what I can, when I can.)
 
EDIT: I finally ended up using the /etc/rc.local method.  Thank-you @Werner and @guidol.

on my BananaPi M1 I can only control the green LED, but for that usage I do use the following command-line:
echo 'mmc0' > /sys/class/leds/bananapi:green:usr/trigger only green LED available: # ls -l /sys/class/leds/ lrwxrwxrwx 1 root root 0 Sep 11 22:11 bananapi:green:usr -> ./../devices/platform/leds/leds/bananapi:green:usr  

for the LEDs you can try the following:

ls -l /sys/class/leds
(here as example from a NanoPi Neo2):
lrwxrwxrwx 1 root root 0 Feb 20 21:50 nanopi:green:status -> ../../devices/platform/leds/leds/nanopi:green:status
lrwxrwxrwx 1 root root 0 Feb 20 21:50 nanopi:red:pwr -> ../../devices/platform/leds/leds/nanopi:red:pwr
 
then echo none to the trigger of the led-name: 
 
echo 'none' > /sys/class/leds/[name_of_the_led]/trigger
 
so it should look like this:
 
echo 'none' > /sys/class/leds/nanopi:green:status/trigger
 
You only have to check the led-names of your board and add the commands in /etc/rc.local before "exit 0"

@guidol, I was talking with @Igor these days and I think the main issue is how slow (and prone to errors) is the repository generator scripts for generating packages for all releases... it's time consuming and requires a lot of efforts from him. I'm taking a look at the scripts to see if I find a way to optimize it. Older releases must be support as `csc` I think.
 
And yes, I'm using exactly the repositories you suggested, thanks:
 
deb http://ports.ubuntu.com/ xenial main restricted universe multiverse #deb-src http://ports.ubuntu.com/ xenial main restricted universe multiverse deb http://ports.ubuntu.com/ xenial-security main restricted universe multiverse #deb-src http://ports.ubuntu.com/ xenial-security main restricted universe multiverse deb http://ports.ubuntu.com/ xenial-updates main restricted universe multiverse #deb-src http://ports.ubuntu.com/ xenial-updates main restricted universe multiverse deb http://ports.ubuntu.com/ xenial-backports main restricted universe multiverse #deb-src http://ports.ubuntu.com/ xenial-backports main restricted universe multiverse  
By the way now it's clearly that the affected packages are only the ones that are build by Armbian, not the packages that are provided by the official Ubuntu repositories.

Downloaded new image Armbian_21.08.1_Bananapi_buster_current_5.10.60.img today, flashed it to sdcard and started with a Unifying reciever plugged-in. Everything was fine, kernel starts without any troubles. Thanks for providing a new installation image!

Yes,  Bullseye will be supported while Buster phases out but may take a few additional month to get things prepared.

Also for other reason. We keep well known and those a bit less known wireless drivers in best possible shape and bundled with kernels we provide. In theory - users should not need to compile exotic drivers that Linux doesn't support (well enough) on their own, but all dependencies are ready (kernel headers, compilers) - so you can. For things we don't cover, can't bundle (zfs) or for experimenting ...
 

We all are 
 
It is impossible to know everything, especially in this tech world full of complicated details.

In fact it is. Starting with v197 systemd:
https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html/networking_guide/sec-understanding_the_predictable_network_interface_device_names
 

@gounthar also maybe here some other idea?
https://hackaday.com/2021/08/16/new-part-day-raspberry-pi-hat-for-ieee1588-precision-time-protocol/

As Hirsute Hippo is at this time also a unsupported OS - there is another catch to get the lighthttpd of pihole working with the Hippo  
 
While using the PIHOLE_SKIP_OS_CHECK=true the install-routine cant restart the lighthttpd correctly, because the package 
lighttpd-mod-deflate
is missing
 
When the install routine does try to restart the lighthttpd it fails with:
 
journalctl -u lighttpd configfile.c.461) Warning: "mod_compress" is DEPRECATED and has been replaced with "mod_deflate". A future release of lighttpd 1.4.x will not contain mod_compresss and lighttpd may fail to start up plugin.c.195) dlopen() failed for: /usr/lib/lighttpd/mod_deflate.so /usr/lib/lighttpd/mod_deflate.so: cannot open shared object file: No such file or directory server.c.1238) loading plugins finally failed  
The Hippo has no mod_compress in the lighthttpd  but its searching for the replacement mod_deflate
 
mod_deflate can be installed via 
apt install lighttpd-mod-deflate
 
While there were also other requirements missing on new installs of pihole I did use the following install-command:
 
apt install php-cgi php-common php php-sqlite3 dhcpcd5 lighttpd-mod-deflate -y && curl -sSL https://install.pi-hole.net | PIHOLE_SKIP_OS_CHECK=true sudo -E bash  
As a "goodie" you can edit after the installation od pihole the /etc/lighttpd/lighttpd.conf and do the follwoing replacement:
change line "mod_compress", against "mod_deflate", then save/exit and restart lighthttpd with 
/etc/init.d/lighttpd restart
 
This way I got pihole running under Hirsute Hippo  
 

Just had the same problem as well, was running Buster without an issue on my C2 and needed to move to Focal for a few annoying reasons using the non desktop download https://redirect.armbian.com/region/AS/odroidc2/Focal_current and can see I also have the same issue with uboot failing to find the network adapter. I can pull the version out of the running Bionic image and then dd it onto the eMMC.
I eventually got my host working by taking the uboot from Bionic:
wget https://armbian.systemonachip.net/archive/odroidc2/archive/Armbian_20.02.8_Odroidc2_bionic_current_5.4.28_desktop.7z 7z e Armbian_20.02.8_Odroidc2_bionic_current_5.4.28_desktop.7z dd if=Armbian_20.02.8_Odroidc2_bionic_current_5.4.28_desktop.img of=bionicuboot.bin bs=512 seek=1 skip=1 count=4096 then put onto the emmc: dd if=bionicuboot.bin of=/dev/sdb bs=512 seek=1 skip=1  
Further edit.. I am going to search for my serial console tonight when I get home to help debug the root cause. I am also running the same C2 board revision as @guidol as per this post: 
 

Yes - looks like you're right! Thanks for pointing me in this direction. I'll update the thread when I found a solution (other than plugging in the Arduino after the boot) in case someone else has similar issues.

Cheers,
Julius

So, 
after struggling for quite some time i finally was able to get things back to normal without losing data (at least i think so).
 
The problem was apparently a broken kernel upgrade to version 5.10.43 . There were broken symlinks and not only. 
 
In the end what solved it was the following:
I first put the latest stable armbian on an sd card and booted with it. then i actually upgraded that image to the latest kernel and copied all version related files from /boot of the sd card to the /boot of the mmc. I also copied the 5.10.45 modules from /lib/module from the sd card to the mmc.
Fixed all symlinks in /boot and then the device finally booted. After that it was all about reinstalling kernel headers, cleaning up wrong zfs versions and packages and rebooting frequently enough in between
 
Hope that i didnt break too much and that this helps someone.

Okay, I'm a noob but finally it works. .dts for anyone that is curious. now i just need to enable LCD in u-boot
 
/dts-v1/; #include "sun4i-a10.dtsi" #include "sunxi-common-regulators.dtsi" #include <dt-bindings/gpio/gpio.h> #include <dt-bindings/input/input.h> #include <dt-bindings/interrupt-controller/irq.h> #include <dt-bindings/pwm/pwm.h> / { model = "Cubietech Cubieboard"; compatible = "cubietech,a10-cubieboard", "allwinner,sun4i-a10"; aliases { serial0 = &uart0; }; chosen { stdout-path = "serial0:115200n8"; }; hdmi-connector { compatible = "hdmi-connector"; type = "a"; port { hdmi_con_in: endpoint { remote-endpoint = <&hdmi_out_con>; }; }; }; }; &ahci { target-supply = <&reg_ahci_5v>; status = "okay"; }; &codec { status = "okay"; }; &cpu0 { cpu-supply = <&reg_dcdc2>; }; &de { status = "okay"; }; &ehci0 { status = "okay"; }; &ehci1 { status = "okay"; }; &emac { phy-handle = <&phy1>; status = "okay"; }; &emac_sram { status = "okay"; }; &hdmi { status = "okay"; }; &hdmi_out { hdmi_out_con: endpoint { remote-endpoint = <&hdmi_con_in>; }; }; &i2c0 { status = "okay"; axp209: pmic@34 { reg = <0x34>; interrupts = <0>; }; }; &i2c1 { status = "okay"; }; &ir0 { pinctrl-names = "default"; pinctrl-0 = <&ir0_rx_pins>; status = "okay"; }; &mdio { status = "okay"; phy1: ethernet-phy@1 { reg = <1>; }; }; &mmc0 { vmmc-supply = <&reg_vcc3v3>; bus-width = <4>; cd-gpios = <&pio 7 1 GPIO_ACTIVE_LOW>; /* PH1 */ status = "okay"; }; &ohci0 { status = "okay"; }; &ohci1 { status = "okay"; }; &otg_sram { status = "okay"; }; &pio { usb0_id_detect_pin: usb0-id-detect-pin { pins = "PH4"; function = "gpio_in"; bias-pull-up; }; usb0_vbus_detect_pin: usb0-vbus-detect-pin { pins = "PH5"; function = "gpio_in"; bias-pull-down; }; }; &reg_ahci_5v { status = "okay"; }; #include "axp209.dtsi" &ac_power_supply { status = "okay"; }; &reg_dcdc2 { regulator-always-on; regulator-min-microvolt = <1000000>; regulator-max-microvolt = <1400000>; regulator-name = "vdd-cpu"; }; &reg_dcdc3 { regulator-always-on; regulator-min-microvolt = <1000000>; regulator-max-microvolt = <1250000>; regulator-name = "vdd-int-dll"; }; &reg_ldo1 { regulator-name = "vdd-rtc"; }; &reg_ldo2 { regulator-always-on; regulator-min-microvolt = <3000000>; regulator-max-microvolt = <3000000>; regulator-name = "avcc"; }; &reg_usb0_vbus { status = "okay"; }; &reg_usb1_vbus { status = "okay"; }; &reg_usb2_vbus { status = "okay"; }; &spi0 { pinctrl-names = "default"; pinctrl-0 = <&spi0_pi_pins>, <&spi0_cs0_pi_pin>; status = "okay"; }; &uart0 { pinctrl-names = "default"; pinctrl-0 = <&uart0_pb_pins>; status = "okay"; }; &usb_otg { dr_mode = "host"; status = "okay"; }; &usbphy { pinctrl-names = "default"; pinctrl-0 = <&usb0_id_detect_pin>, <&usb0_vbus_detect_pin>; usb0_id_det-gpios = <&pio 7 4 (GPIO_ACTIVE_HIGH | GPIO_PULL_UP)>; /* PH4 */ usb0_vbus_det-gpio = <&pio 7 5 (GPIO_ACTIVE_HIGH | GPIO_PULL_DOWN)>; /* PH5 */ usb0_vbus-supply = <&reg_usb0_vbus>; usb1_vbus-supply = <&reg_usb1_vbus>; usb2_vbus-supply = <&reg_usb2_vbus>; status = "okay"; };  

I own a few Android TV boxes that have poor thermal designs that are prone to overheating when under sustained load. This can either cause your device to significantly slow down or shut down entirely. This can be fixed by cutting a hole in the bottom on your TV box above the SoC and sticking a small USB fan on it. In my case I am using a AC Infinity 40mm x 20mm USB Fan that cost me £10.
 
CH340-fan-control is a python script to only activate my TV boxes USB fan when required by using a USB relay module. I'd expect somebody (or several somebodies) have already wrote a similar script for the same device but I failed to find it so here is my effort at fixing this common TV box issue. Hopefully someone else will find it useful.

https://github.com/danboid/CH340-fan-control

 

Been dreaming of this one for a while.  Finally got a weekend to focus on it recently.  I'm hoping someone is eager to take what I've done and move It along some more.

Here's what we have so far.

* a linux 'family' called virtual.conf
* a kernel config called linux-virtual-current.config
* a board called virtual-qemu.wip
 
The result is a full HVM accelerated armbian image with a kernel compiled with all the virtio drivers for disk, network and video.   Also a u-boot.bin made for qemu that can boot the image when used as the qemu bios/firmware
 
I've ran it as a VM on ubuntu using plain qemu on a Ampere eMag box.. and using UTM (qemu) on Apple M1 in MacOS

this is using u-boot, not uEFI.. and you need to copy the u-boot.bin manually from cache/sources/u-boot...../u-boot.bin and use it as your chosen bios for qemu.  I left some quick breadcrumbs on how to launch within the board config file.
 
I want to keep the u-boot option, but obviously we need this to support uEFI booting to be viable for the masses.

Next steps:

* automatically resize and convert resulting image to qcow2 format
* solve how to add cloud-init to image
* solve for installing grubEFI for booting and whatever partition layout is needed
* figure a proper way to write uboot to the image so thet qemu can boot without loading as a bios
* strip extra hardware drivers out of kernel and make this thing lean

PS Did I mention Desktop Works too?

 
 
 

Hello everyone, I wanted to propose that the q8 tablets be included in the compilation script, I have several q8 tablets, at the beginning I used my own rootfs, but armbian is fantastic !! counting the modifications I make to the armbian rootfs I think it would be easy, in the firmware repository you already have the majority of hardware such as 8723 and other Wi-Fi chips, with respect to the uboot the templates that already incorporate the main repository work almost perfectly, no I know, could I help, I have the components, the dtb and the compiled uboot, how do you see it? Greetings

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
 
 
 
 
 
 
 
 
 
 
 

I was thinking exactly the same question. Why do you bother and waste your time here if you don't like Armbian?
Lately I've red few complaints of people who have "many years of experience". But they don't want to bother reading and learning new skills. 
Experience is not the same as knowledge
As knowledge is not the same as experience

With experience you can have gained knowledge about much but not being specialized at one thing, or know a lot about a small section of the industry and be blind to all other.

Thousands of people happily use Armbian on their devices and for 99% of the usecases everything is fine. The other 1% we try to help here. 

I've made tons of informative videos about SBCs. I show how to do all the basic stuff, and some more advanced things. 
https://www.youtube.com/channel/UCpv7NFr0-9AB5xoklh3Snhg/search?query=armbian
The forum also has the Reviews, Tutorials and Hacks section where almost everything you could want to learn about Armbian is explained.
https://forum.armbian.com/forum/40-reviews-tutorials-hardware-hacks/
Then there is Armbian Docs also full of information.
https://docs.armbian.com/

All these things have cost us time, and so also money. We are here to serve. And then you say our work is "garbage".
Sorry, but I do not take that lightly.

You can't teach someone who is convinced to know it all. Greetings.

I have sent that fallback vdd voltage patch to Marvell: https://github.com/MarvellEmbeddedProcessors/A3700-utils-marvell/pull/18

Per meeting, we're still trying to improve our responses to "unsupported' inquries.

current thoughts
 
* revise "invalid label"
* focus on moving messages