Jump to content

Search the Community

Showing results for tags 'cubietruck'.

  • Search By Tags

    Type tags separated by commas.
  • Search By Author

Content Type


  • Community
    • Announcements
    • Feature Requests
  • Using Armbian
    • Beginners
    • Software, Applications, Userspace
    • Advanced users - Development
  • Upcoming Hardware (WIP)
    • News
    • Odroid M1
    • ROCK 5B
    • Orange Pi 5
  • Maintained Hardware
    • Board does not start
    • Amlogic meson
    • Allwinner sunxi
    • Marvell mvebu
    • Rockchip
    • Other families
  • Unmaintained (CSC/EOL/TVB) / Other
    • TV boxes
    • Off-topic
    • Amlogic meson
    • Allwinner sunxi
    • Marvell mvebu
    • Rockchip
    • Other families

Find results in...

Find results that contain...

Date Created

  • Start


Last Updated

  • Start


Filter by number of...


  • Start






Website URL







  1. Hi. Armbian 21.02.1 / 5.15.74-sunxi (22.08.6 SMP) / Debian 11.5 is working flawlessly on my cubietruck for several days, and then just hangs. I've studied the armbian-hardware-monitor.log, systemlog, run a 2-minute periodic cron to watch the temperature, and even added a serial comsole in an attempt to find out what might be the cause. I have not seen any weird indications in these logs. Temperature stays between 37 and 45 degrees. When the system hangs, there are no error messages on the consoles or via the serial comm. Pings are unresponded then, and magic sysrq won't work then. Armbian is run on a sata harddisk, there are some harddisks attached via an USB hub too but not involved in system-critical tasks. Network is LAN-based. Can someone recommend what else than desribed above I could do or check to analyze what's going on and leads to the hangup. Thanks in advance.
  2. /var/log/Xorg.0.log: [ 59.326] (EE) AIGLX error: sun4i-drm does not export required DRI extension [ 59.550] (II) IGLX: Loaded and initialized swrast [ 59.550] (II) GLX: Initialized DRISWRAST GL provider for screen 0 [ 59.550] (II) Initializing extension XFree86-VidModeExtension [ 59.551] (II) Initializing extension XFree86-DGA [ 59.553] (II) Initializing extension XFree86-DRI [ 59.553] (II) Initializing extension DRI2 [ 59.564] (II) modeset(0): Damage tracking initialized [ 59.565] (II) modeset(0): Setting screen physical size to 508 x 285 [ 60.561] (II) config/udev: Adding input device sunxi-ir (/dev/input/event1) [ 60.561] (**) sunxi-ir: Applying InputClass "libinput keyboard catchall" [ 60.561] (II) LoadModule: "libinput" [ 60.562] (II) Loading /usr/lib/xorg/modules/input/libinput_drv.so [ 60.624] (II) Module libinput: vendor="X.Org Foundation" [ 60.624] compiled for 1.20.4, module version = 0.29.0 [ 60.624] Module class: X.Org XInput Driver [ 60.624] ABI class: X.Org XInput driver, version 24.1 [ 60.624] (II) Using input driver 'libinput' for 'sunxi-ir' [ 60.624] (**) sunxi-ir: always reports core events [ 60.624] (**) Option "Device" "/dev/input/event1" [ 60.625] (**) Option "_source" "server/udev" [ 60.703] (II) event1 - sunxi-ir: is tagged by udev as: Keyboard Pointingstick [ 60.708] (II) event1 - sunxi-ir: device is a pointer [ 60.708] (II) event1 - sunxi-ir: device is a keyboard [ 60.710] (II) event1 - sunxi-ir: device removed [ 60.749] (II) libinput: sunxi-ir: needs a virtual subdevice [ 60.749] (**) Option "config_info" "udev:/sys/devices/platform/soc/1c21800.ir/rc/rc0/input1/event1" [ 60.749] (II) XINPUT: Adding extended input device "sunxi-ir" (type: MOUSE, id 6)
  3. Since the CT (the A20 one, not the CT+) has been moved to CSC status, I've build a 22.04/jammy minimal image for my CT, and I figured I might as well share it with you. The only changes to "pure" armbian are some power management debug options in the kernel. https://github.com/IGNNE/cubietruck-armbian-unofficial/releases/tag/22.04-2022-09-09 SHA256 of zip file: 9d0028a9f5c6258a739f52f447bf4400d20fec52358f5006ae8a26b602acdfc0
  4. Hi, is this the right place to ask about support to configure a dtb overlay? I created a .dts file for my ILI9341 TFT display which is connected to a cubietruck running armbian. most of it I copied from the internet and adapted my changed (pin configuration and spi device). Previously I my configuration was done in a fex file and also created a pcb to connect the display to the cubietruck. See german documentation https://klautesblog.blogspot.com/2015/12/ili9341-22-tft-display-am-cubietruck.html?m=1 It worked perfectly but now I’m facing some issues with the new system. Armbian: Armbian 21.08.1 Focal Kernel version: Linux cubietruck 5.10.60-sunxi #21.08.2 SMP Tue Sep 14 16:28:44 UTC 2021 armv7l armv7l armv7l GNU/Linux One of the attachments (sorry about their file-names) shows dmesg output with the messages related to my settings. The kernel complains about that the pins are already in use. But now i'm not sure what to disable and how to do it. Configuring the fex file was easygoing but the dts stuff is new to me. maybe someone has a hint for me? Thank you, kind regards Kai
  5. Clean system does not start after migrating to SSD using armbian-config. Bootlog:
  6. Hello, Trying to figure out to get bluetooth working on Cubietruck with Armbian Buster mainline based kernel 5.4.y Installed all software but bluetoothctl keeps telling me there is no default controller. Seems to me the drivers are not loaded/activated. Is this supposed to work or m i trying to fix someting unfixable. Please bump me in the right direction.. Tjabks!
  7. For the second time within about 4 weeks my cubietruck is not coming up anymore after a sudo apt upgrade and reboot. Is there something systematically breaking? I think it is the initramfstools that is breaking it? Now, I have no radio, alarm-clock and I cannot turn on my coffee-maker over the internet and I will probably have to spend a day etching a new SD card etc. I bought a new SD card last time this happened since I figured ist would be related to that, now I think it is a software thing. I use the cubietruck headless over ssh and have no real video output, just audio. I also need to do some cumbersome operations to get it out of the box, it is in from which it is controlling all sorts of remote controls for receivers, projectors etc. So it is almost easier to etch a new card, but I am afraid I will find myself with the same problem in a few weeks again. I used the following image Armbian_21.05.1_Cubietruck_buster_current_5.10.34_xfce_desktop.img The latest upgrade did the following: The following packages will be upgraded: code firefox-esr libgssapi-krb5-2 libjavascriptcoregtk-4.0-18 libk5crypto3 libkrb5-3 libkrb5support0 libnss-myhostname libpam-systemd libsystemd0 libudev1 libwebkit2gtk-4.0-37 linux-u-boot-cubietruck-current systemd systemd-sysv udev In particular: Processing triggers for initramfs-tools (0.133+deb10u1) ... update-initramfs: Generating /boot/initrd.img-5.10.43-sunxi update-initramfs: Converting to u-boot format Is it now trying to boot from ramfs rather than the SD-card? Any suggestions on what I could do in a more "minimally invasive" way to get it back to work? Any updates I should hold back in the future to keep this from happening?
  8. Hi All I am not able to run Armbian Buster from the Downloads page (https://www.armbian.com/cubietruck/) on the CT board. Other images run fine, including: - Armbian_5.65_Cubietruck_Debian_stretch_next_4.14.78 (from archive) - Armbian_5.65_Cubietruck_Ubuntu_bionic_next_4.14.78 (from archive) - openwrt-19.07.7-sunxi-cortexa7-sun7i-a20-cubietruck-squashfs-sdcard.img.gz (from OpenWrt downloads site) The problem is that it endlessly reboots after resetting the CPU. The output from the serial port is shown below. I can interrupt the Autoboot and get to the Uboot console ok. The output from printenv is also shown below. Any suggestions as to what might be the problem would be greatly appreciated. If anyone has this set up working, a copy of the printenv output would be great to compare. Thanks in advance for any help. T
  9. Hello, on Cubietruck, until I upgrade my ARMBIAN server from Jessie to Stretch with kernel 4.13.16-sunxi, I could use the VGA output for display. After the upgrade, I don't have any display from VGA. In /boot/boot.cmd, I have the following kernel bootargs : "console=tty1 root=/dev/mmcblk0p1 rootwait rootfstype=ext4 sunxi_ve_mem_reserve=0 sunxi_g2d_mem_reserve=0 sunxi_no_mali_mem_reserve sunxi_fb_mem_reserve=16 hdmi.audio=EDID:0 disp.screen0_output_mode=1920x1080p60 panic=10 consoleblank=0 enforcing=0 loglevel=1" Any advice ? Thanks in advance, Romain
  10. Hi Armbians In the last years I had the pleasure to have more then 30 Cubietruck boards in my hands to work with. Condition of the boards ranged from "new and still sealed" to "working but has been running for some months 24/7 alraedy". In this time, I learned a lot about this hardware and I learned that none of them seems to be 100% like any other of them. While one board crushes immediately when the power input goes under 5V for some secounds, another board in the same condition, same CT version and production date seems not to care about this and keeps working. One of the most important points for stability is the network plug used. So what network plugs did you use with success? I am running 95% of my CT boards with this plugs. Both seem to do the job fine and do not care about being in use 24/7: https://www.amazon.de/HomeSpot-Raspberry-Ladegerät-Netzschalter-Kompatibel/dp/B078567K85/ref=sr_1_37?dchild=1&keywords=HomeSpot&qid=1612923046&sr=8-37 https://www.amazon.de/AmazonBasics-USB-Ladeadapter-Ampere-mit-Anschlüssen-Schwarz/dp/B0773J952F/ref=sr_1_2?__mk_de_DE=ÅMÅŽÕÑ&dchild=1&keywords=amazon%2Bbasics%2B5v%2B2%2C4%2Ba&qid=1612923159&sr=8-2&th=1
  11. Hi, 2 weeks ago I upgraded my Cubietruck to newest Armbian version: root@cubietruck04:/var/log# uname -a Linux cubietruck04 5.10.4-sunxi #20.11.6 SMP Sun Jan 3 21:28:45 CET 2021 armv7l GNU/Linux root@cubietruck04:/var/log# lsb_release -a No LSB modules are available. Distributor ID: Debian Description: Debian GNU/Linux 10 (buster) Release: 10 Codename: buster Since that upgrade the Cubie is crashing often compared to the last years ( every ~3 days), in the last 3 years I have never observed that. Please help me to find out the issue. From kern.log I see 2 different crash reasons: Jan 27 16:32:54 cubietruck kernel: [532479.453218] Unable to handle kernel NULL pointer dereference at virtual address 00000120 Jan 30 07:03:30 cubietruck04 kernel: [48303.784688] Unable to handle kernel paging request at virtual address c0008f38 I'm using that Cubie as jenkins node (not for SW build, just as testing device). I installed (as far as I remember) additional packets: minicom, openjdk-11, jenkins client from jenkins web GUI. There is a VSCom Box 8 to 1 Serial -> USB converter connected, but also since years. armbianmonitor-u.txt faillog kern.log
  12. Hi Armbians I am running mulitiple TOR network relays on Cubietruck boards (Cubieboard 3) in different Datacenters with synchronous 100 MBit/s internet connection each board (by ethernet plug) for 1- 1,5 years now. At the beginning each board could handle 25 MBit/s incomming and outgoing traffic the same time easy and 24/7. The boards are running the latest Armbian build with kernel headers installed and full firmware package. But now, as you can see here, my Cubietrucks are getting slower after time, with the network traffic they can handle via eth0: https://metrics.torproject.org/rs.html#details/EC9C4CDB403204731122C9D3FA44DFAE667DC82D They have been kept up to date and are rebootet and the system cleaned once a week. So whats the problem? SD card getting old and dieing? Is there a way to speed them up again and (even better) tune the throughput without risking stability? Please help
  13. Linux cubietruck 5.10.4-sunxi #20.11.6 SMP Sun Jan 3 21:28:45 CET 2021 armv7l GNU/Linux ------------[ cut here ]------------ [ 1.304783] WARNING: CPU: 0 PID: 1 at arch/arm/mm/ioremap.c:287 __arm_ioremap_pfn_caller+0x13f/0x14c [ 1.304791] Modules linked in: [ 1.304812] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 5.10.4-sunxi #20.11.6 [ 1.304818] Hardware name: Allwinner sun7i (A20) Family [ 1.304852] [<c010c9ed>] (unwind_backtrace) from [<c0109501>] (show_stack+0x11/0x14) [ 1.304873] [<c0109501>] (show_stack) from [<c0966dcb>] (dump_stack+0x77/0x84) [ 1.304892] [<c0966dcb>] (dump_stack) from [<c011ae99>] (__warn+0xad/0xc0) [ 1.304907] [<c011ae99>] (__warn) from [<c0960d0b>] (warn_slowpath_fmt+0x43/0x7c) [ 1.304923] [<c0960d0b>] (warn_slowpath_fmt) from [<c011335b>] (__arm_ioremap_pfn_caller+0x13f/0x14c) [ 1.304938] [<c011335b>] (__arm_ioremap_pfn_caller) from [<c0113397>] (__arm_ioremap_caller+0x2f/0x38) [ 1.304955] [<c0113397>] (__arm_ioremap_caller) from [<c05b8b07>] (simplefb_probe+0x19b/0x6b8) [ 1.304974] [<c05b8b07>] (simplefb_probe) from [<c064f8bb>] (platform_drv_probe+0x33/0x68) [ 1.304989] [<c064f8bb>] (platform_drv_probe) from [<c064dd27>] (really_probe+0x13b/0x354) [ 1.305001] [<c064dd27>] (really_probe) from [<c064e105>] (driver_probe_device+0xa9/0x168) [ 1.305016] [<c064e105>] (driver_probe_device) from [<c064c7a1>] (bus_for_each_drv+0x4d/0x78) [ 1.305031] [<c064c7a1>] (bus_for_each_drv) from [<c064db7f>] (__device_attach+0x8f/0xf0) [ 1.305044] [<c064db7f>] (__device_attach) from [<c064d0ff>] (bus_probe_device+0x5b/0x60) [ 1.305059] [<c064d0ff>] (bus_probe_device) from [<c064a78b>] (device_add+0x2e7/0x564) [ 1.305076] [<c064a78b>] (device_add) from [<c07c808d>] (of_platform_device_create_pdata+0x65/0x88) [ 1.305094] [<c07c808d>] (of_platform_device_create_pdata) from [<c0e1db5b>] (simplefb_init+0x4f/0x60) [ 1.305112] [<c0e1db5b>] (simplefb_init) from [<c0101c8d>] (do_one_initcall+0x39/0x1ac) [ 1.305128] [<c0101c8d>] (do_one_initcall) from [<c0e00ee5>] (kernel_init_freeable+0x1bd/0x208) [ 1.305144] [<c0e00ee5>] (kernel_init_freeable) from [<c096bdb9>] (kernel_init+0xd/0xe0) [ 1.305159] [<c096bdb9>] (kernel_init) from [<c0100159>] (ret_from_fork+0x11/0x38) [ 1.305167] Exception stack(0xc151ffb0 to 0xc151fff8) [ 1.305178] ffa0: 00000000 00000000 00000000 00000000 [ 1.305189] ffc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 [ 1.305199] ffe0: 00000000 00000000 00000000 00000000 00000013 00000000 [ 1.305215] ---[ end trace 871998d831abfa15 ]---
  14. Hello, I have a cubitruck With armbian and it runs the most time fine. Now i'm Not AT Home and the cubi is Out, I See in my router That He is Not running. I Can't connect over ssh. Who can I Look after a reboot when i'm AT Home what is the problem for going down. Thank you
  15. Hi, I'm using a CubieTruck running Armbian 5.8.16. /dev/ttyS2 works fine if I use the 4.19.62 dtb but not when using the 5.8.16 dtb. I am using the uart2 overlay and param_uart2_rtscts. If I try to access the port with picocom it reports "Filedes is not a tty". Commenting the param_uart2_rtscts line makes no difference. It appears that uart2 isn't being setup as a serial port when using the 5.8.16 dtb (and overlays). But the kernel must be okay because it works with the old dtb. Does anybody have a solution here ? Or can you tell me where the sources for the dtb and overlay are ? The copies on github seem old. Thanks, Steven
  16. After having my old debian (wheezy? or jessy?) unbootable from systemd update I decided to clean install. Having gotten a good Power supply, an A1 Speed 10 SD card, etcher image, and armbian debian 20.08 (also tried 20.07), The board boots (Welcome to armbian) up to "network interfaces up) - then the screen goes blank/black, and I get the green led heardbeat (slow blinking) for a while. Pushing power again the board shuts down (green LED blinking rapidly for a moment, then red power LED comes off). I have had installed boot to nand / Sata disk before but all that shouldn't matter I think because the boot from SD Card seems successful - why could it be that the Screen goes black and I don't get to the login after the 'network interfaces iup' part of booting? Update: this is not a boot but exclusively a screen connection problem - after a while my router picked up on the board and I could ssh into it - so it's a graphics problem, likely the VGA connection is turned off by default or something. And now that that became clear, the solution was also already here: https://forum.armbian.com/topic/445-debian-images-cubietruck-vga-output-problem/
  17. Hi, I'm using Armbian Linux on a Cubietruck A20 device configured as a media, file and backup server. Unfortunately while trying to fix a persistent SATA-cable connection problem I accidentally pushed the FEL button on the device. Now the device is always booting in FEL mode searching for USB devices, and I'm unable to reverse this. I have been looking at multiple pages about the FEL mode but I'm unable to find useful information on how to quit or exit this FEL mode and to have the cubietruck booting as it did before. Although I'm not a Linux novice, the information about FEL is quite complex and I have to admit I'm clueless about how to fix this situation. Please, any help on how to disable this FEL mode is really appreciated. It is heartbreaking to lose my server, files, music and all :-\ https://linux-sunxi.org/FEL/USBBoot Kind regards, Michael2
  18. Symptoms: Board does not boot Armbian from inserted SD card, but may boot other distributions (based on old/legacy u-boot). Following or similar output can be grabbed from the serial console: U-Boot SPL 2017.01-armbian (Feb 02 2017 - 03:04:04) DRAM: 2048 MiB Trying to boot from MMC1MMC: no card present spl: mmc init failed with error: -123 SPL: failed to boot from all boot devices ### ERROR ### Please RESET the board ### The key message here is "MMC: no card present" Most likely cause: Malfunctioning microSD slot card detect switch. It can be verified either visually (with a magnifying glass) or electronically (with a multimeter) - at least in the slots used on Orange Pi boards and on Pine64 the pin near the switch should be shorted to the ground (i.e. SD slot casing) when card is inserted. Illustration (example) of a working switch: Verification (with a multimeter): Probe 1 - slot pin near the switch (may be different for different slot types, but at least true for Oranges and Pine64) Probe 2 - microSD slot casing or other parts connected to GND (not shown on the photo) No card - circuit is open Card inserted - circuit is shorted Photos - card is not inseted on the left and is fully inserted on the right: Orange Pi Pine64 (switch is more visible) Can it be fixed? Yes if the switch is not broken completely, by carefully adjusting (bending) the stationary contact (left on the pictures and photos, it usually is a part of the SD slot casing) i.e using a needle so it touches the moving contact (mostly hidden inside the slot on the photos) when card is inserted and not touching it when it is not inserted.
  19. Hi, I try to change the language of the last OS Buster of a Cubietruck 3 in FR. The language is always in US. Thanks
  20. Hi, I'm working with mpd on armbian 20.02.0 with i2s device and found some problem: periodically sound is interrupted. I enable verbose logging in mpd and I get message: May 20 04:36 : alsa_output: Underrun on ALSA device "hw:0,0" May 20 04:36 : alsa_output: Underrun on ALSA device "hw:0,0" May 20 04:37 : alsa_output: Underrun on ALSA device "hw:0,0" This is not permanent and some time maybe work fine, but if it starts, messages go with an interval of 10-11 seconds until I restart mpd. I rebuilt armbian with enabled ALSA debug options CONFIG_SND_PCM_XRUN_DEBUG, CONFIG_SND_VERBOSE_PROCFS, CONFIG_SND_DEBUG and try again. This is result with my i2s card and echo 3 > /proc/asound/card0/pcm0p/xrun_debug May 20 03:30:59 localhost kernel: [ 1099.726101] i2s_clock_board: i2s_clock_board_trigger May 20 03:30:59 localhost kernel: [ 1099.726136] I2S Command State 0 May 20 03:30:59 localhost kernel: [ 1099.726200] asoc-simple-card sound_i2s: XRUN: pcmC1D0p:0 May 20 03:30:59 localhost kernel: [ 1099.726213] CPU: 0 PID: 1348 Comm: kworker/0:1 Tainted: G C O 5.4.18-sunxi #20.02.0 May 20 03:30:59 localhost kernel: [ 1099.726216] Hardware name: Allwinner sun7i (A20) Family May 20 03:30:59 localhost kernel: [ 1099.726239] Workqueue: events_freezable_power_ thermal_zone_device_check May 20 03:30:59 localhost kernel: [ 1099.726268] [<c010da8d>] (unwind_backtrace) from [<c010a0ad>] (show_stack+0x11/0x14) May 20 03:30:59 localhost kernel: [ 1099.726282] [<c010a0ad>] (show_stack) from [<c093704f>] (dump_stack+0x6f/0x7c) May 20 03:30:59 localhost kernel: [ 1099.726344] [<c093704f>] (dump_stack) from [<bf856305>] (__snd_pcm_xrun+0x101/0x108 [snd_pcm]) May 20 03:30:59 localhost kernel: [ 1099.726384] [<bf856305>] (__snd_pcm_xrun [snd_pcm]) from [<bf8563b3>] (snd_pcm_update_state+0xa7/0xac [snd_pcm]) May 20 03:30:59 localhost kernel: [ 1099.726420] [<bf8563b3>] (snd_pcm_update_state [snd_pcm]) from [<bf856549>] (snd_pcm_update_hw_ptr0+0x191/0x5a4 [snd_pcm]) May 20 03:30:59 localhost kernel: [ 1099.726455] [<bf856549>] (snd_pcm_update_hw_ptr0 [snd_pcm]) from [<bf8569a7>] (snd_pcm_period_elapsed+0x4b/0x90 [snd_pcm]) May 20 03:30:59 localhost kernel: [ 1099.726483] [<bf8569a7>] (snd_pcm_period_elapsed [snd_pcm]) from [<bf84928f>] (dmaengine_pcm_dma_complete+0x3b/0x3c [snd_pcm_dmaengine]) May 20 03:30:59 localhost kernel: [ 1099.726500] [<bf84928f>] (dmaengine_pcm_dma_complete [snd_pcm_dmaengine]) from [<c05f9fdf>] (vchan_complete+0x133/0x140) May 20 03:30:59 localhost kernel: [ 1099.726517] [<c05f9fdf>] (vchan_complete) from [<c0120413>] (tasklet_action_common.constprop.3+0x2f/0x80) May 20 03:30:59 localhost kernel: [ 1099.726531] [<c0120413>] (tasklet_action_common.constprop.3) from [<c01022f7>] (__do_softirq+0xdf/0x288) May 20 03:30:59 localhost kernel: [ 1099.726541] [<c01022f7>] (__do_softirq) from [<c0120333>] (irq_exit+0x7b/0x90) May 20 03:30:59 localhost kernel: [ 1099.726555] [<c0120333>] (irq_exit) from [<c0160233>] (__handle_domain_irq+0x47/0x84) May 20 03:30:59 localhost kernel: [ 1099.726570] [<c0160233>] (__handle_domain_irq) from [<c05ca5dd>] (gic_handle_irq+0x39/0x6c) May 20 03:30:59 localhost kernel: [ 1099.726581] [<c05ca5dd>] (gic_handle_irq) from [<c0101ae5>] (__irq_svc+0x65/0x94) May 20 03:30:59 localhost kernel: [ 1099.726586] Exception stack(0xedae7e30 to 0xedae7e78) May 20 03:30:59 localhost kernel: [ 1099.726593] 7e20: 00000fe0 00000006 fac81000 c010d0f1 May 20 03:30:59 localhost kernel: [ 1099.726603] 7e40: c1054fa8 332c1eac 00005dbf 0000008d 00000045 ecf17b54 c0c51994 1ffffc70 May 20 03:30:59 localhost kernel: [ 1099.726611] 7e60: ee405a78 edae7e80 c010d105 c0935016 200f0033 ffffffff May 20 03:30:59 localhost kernel: [ 1099.726626] [<c0101ae5>] (__irq_svc) from [<c0935016>] (__timer_delay+0x26/0x34) May 20 03:30:59 localhost kernel: [ 1099.726644] [<c0935016>] (__timer_delay) from [<bfa2d3c5>] (sun4i_gpadc_read+0x10d/0x15c [sun4i_gpadc_iio]) May 20 03:30:59 localhost kernel: [ 1099.726677] [<bfa2d3c5>] (sun4i_gpadc_read [sun4i_gpadc_iio]) from [<bfa2d4f5>] (sun4i_gpadc_temp_read+0x29/0x70 [sun4i_gpadc_iio]) May 20 03:30:59 localhost kernel: [ 1099.726691] [<bfa2d4f5>] (sun4i_gpadc_temp_read [sun4i_gpadc_iio]) from [<bfa2d561>] (sun4i_gpadc_get_temp+0x25/0x54 [sun4i_gpadc_iio]) May 20 03:30:59 localhost kernel: [ 1099.726703] [<bfa2d561>] (sun4i_gpadc_get_temp [sun4i_gpadc_iio]) from [<c07a456f>] (thermal_zone_get_temp+0x33/0x44) May 20 03:30:59 localhost kernel: [ 1099.726717] [<c07a456f>] (thermal_zone_get_temp) from [<c07a1e21>] (thermal_zone_device_update.part.4+0x21/0xe0) May 20 03:30:59 localhost kernel: [ 1099.726730] [<c07a1e21>] (thermal_zone_device_update.part.4) from [<c012f6d9>] (process_one_work+0x179/0x3cc) May 20 03:30:59 localhost kernel: [ 1099.726740] [<c012f6d9>] (process_one_work) from [<c012fa2f>] (worker_thread+0x103/0x410) May 20 03:30:59 localhost kernel: [ 1099.726752] [<c012fa2f>] (worker_thread) from [<c01340a5>] (kthread+0x109/0x10c) May 20 03:30:59 localhost kernel: [ 1099.726763] [<c01340a5>] (kthread) from [<c01010f9>] (ret_from_fork+0x11/0x38) May 20 03:30:59 localhost kernel: [ 1099.726767] Exception stack(0xedae7fb0 to 0xedae7ff8) May 20 03:30:59 localhost kernel: [ 1099.726773] 7fa0: 00000000 00000000 00000000 00000000 May 20 03:30:59 localhost kernel: [ 1099.726782] 7fc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 May 20 03:30:59 localhost kernel: [ 1099.726789] 7fe0: 00000000 00000000 00000000 00000000 00000013 00000000 May 20 03:30:59 localhost kernel: [ 1099.812099] i2s_clock_board: i2s_clock_board_trigger May 20 03:30:59 localhost kernel: [ 1099.812156] I2S Command State 1 I changed device output to analog codec, rebooted and create armbianmonitor log. Messages about snd_pcm* like messages i2s device, but haven't messages about sun4i_gpadc*. I'm confused and don't know what make further. I played files from connected sata hdd and NAS, but it does not matter. And maybe this issue related kworker problem? Because I periodically see kworker/0:4-events_freezable_power_ in top
  21. Hi there. @Moderators: sorry for double-posting, started here: https://forum.armbian.com/topic/13916-cubietruck-allwinner-a20-spidev-no-such-device/?do=findComment&comment=101122 but might be the wrong section and been overlooked by "cubietruckers". Feel free to delete the one over there. @Moderators: could you verify my account please so that I can edit my posts after posting on the same day? I'm human, I can tell traffic lights from trees, cars, and trucks ;-) Cubietruck. Stock image 20.02. apt-upgraded to 5.4.35-sunxi EDIT: NOTE: just checked the armbianmonitor upload result, which says "5.4.20" at the top - but "uname -r" says "5.4.35", which armbianmonitor Shows further down, too. No changes to device tree files / overlays; no user-overlays installed (tried a lot of things...) Want to use SPI(0). Can't get it to "loop-back" anything. Been through "a lot" and a "lot of hours". I've read the enduser documentation on DT overlays, I've read the README for the sun7i overlays, I've read tons of threads....Is it that hard? Am I too stupid? Q: Shouldn't it (these days) be as simple as putting these three lines into armbianEnv.txt, which I did?: overlay_prefix=sun7i-a20 overlays=spi-spidev param_spidev_spi_bus=0 Q: should there be an overlay "spi0" or "spi" along with spi-spidev above? Q: If yes, then should there be a file /boot/dtb/overlay/sun7i-a20-spi(0).dtbo? I don't have that. For other platforms, there are spi0/1/...dtbo files in there. I only have these: -rw-r--r-- 1 root root 267 Apr 23 18:06 /boot/dtb/overlay/sun7i-a20-analog-codec.dtbo -rw-r--r-- 1 root root 386 Apr 23 18:06 /boot/dtb/overlay/sun7i-a20-can.dtbo -rw-r--r-- 1 root root 5532 Apr 23 18:06 /boot/dtb/overlay/sun7i-a20-fixup.scr -rw-r--r-- 1 root root 500 Apr 23 18:06 /boot/dtb/overlay/sun7i-a20-i2c1.dtbo -rw-r--r-- 1 root root 500 Apr 23 18:06 /boot/dtb/overlay/sun7i-a20-i2c2.dtbo -rw-r--r-- 1 root root 500 Apr 23 18:06 /boot/dtb/overlay/sun7i-a20-i2c3.dtbo -rw-r--r-- 1 root root 766 Apr 23 18:06 /boot/dtb/overlay/sun7i-a20-i2c4.dtbo -rw-r--r-- 1 root root 590 Apr 23 18:06 /boot/dtb/overlay/sun7i-a20-mmc2.dtbo -rw-r--r-- 1 root root 2301 Apr 23 18:06 /boot/dtb/overlay/sun7i-a20-nand.dtbo -rw-r--r-- 1 root root 778 Apr 23 18:06 /boot/dtb/overlay/sun7i-a20-pps-gpio.dtbo -rw-r--r-- 1 root root 443 Apr 23 18:06 /boot/dtb/overlay/sun7i-a20-pwm.dtbo -rw-r--r-- 1 root root 1040 Apr 23 18:06 /boot/dtb/overlay/sun7i-a20-spdif-out.dtbo -rw-r--r-- 1 root root 556 Apr 23 18:06 /boot/dtb/overlay/sun7i-a20-spi-add-cs1.dtbo -rw-r--r-- 1 root root 1093 Apr 23 18:06 /boot/dtb/overlay/sun7i-a20-spi-jedec-nor.dtbo -rw-r--r-- 1 root root 1069 Apr 23 18:06 /boot/dtb/overlay/sun7i-a20-spi-spidev.dtbo -rw-r--r-- 1 root root 808 Apr 23 18:06 /boot/dtb/overlay/sun7i-a20-uart2.dtbo -rw-r--r-- 1 root root 1078 Apr 23 18:06 /boot/dtb/overlay/sun7i-a20-uart3.dtbo -rw-r--r-- 1 root root 513 Apr 23 18:06 /boot/dtb/overlay/sun7i-a20-uart4.dtbo -rw-r--r-- 1 root root 513 Apr 23 18:06 /boot/dtb/overlay/sun7i-a20-uart5.dtbo -rw-r--r-- 1 root root 513 Apr 23 18:06 /boot/dtb/overlay/sun7i-a20-uart6.dtbo -rw-r--r-- 1 root root 513 Apr 23 18:06 /boot/dtb/overlay/sun7i-a20-uart7.dtbo -rw-r--r-- 1 root root 777 Apr 23 18:06 /boot/dtb/overlay/sun7i-a20-w1-gpio.dtbo ttl console reports nothing "strange" I believe: ... [22:44:20:553] 1069 bytes read in 6 ms (173.8 KiB/s) [22:44:20:567] Applying kernel provided DT overlay sun7i-a20-spi-spidev.dtbo [22:44:20:599] 5532 bytes read in 7 ms (771.5 KiB/s) [22:44:20:621] Applying kernel provided DT fixup script (sun7i-a20-fixup.scr) [22:44:20:633] ## Executing script at 44000000 [22:44:20:646] ## Loading init Ramdisk from Legacy Image at 43300000 ... [22:44:20:662] Image Name: uInitrd ... [22:44:28:422] [ 6.431813] spidev spi0.0: probing from DT ... Q: I have no other occurrences of "spi" in dmesg - should I? lsmod lists "spidev". I have NO /proc/device-tree/spi* entries (as other platforms or earlier kernels seem to have (had)) I DO have /proc/device-tree/soc/spi@1c05000 And I do have /dev/spidev0.0 (accessible to root only) $ cat /proc/device-tree/soc/spi@1c05000/status okay $ cat /proc/device-tree/soc/spi@1c05000/spidev@0/status okay I'm positive I've got MISO and MOSI for SPI0 jumpered "short". I have tried spidev_test.c, it transmits, but does not get anything back. $ sudo ./a.out -v -D /dev/spidev0.0 spi mode: 0x0 bits per word: 8 max speed: 500000 Hz (500 KHz) TX | FF FF FF FF FF FF 40 00 00 00 00 95 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF F0 0D |......@.........................| RX | 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................................| Q: Trying it with "--loop" gives "can't set spi mode: Invalid argument", "Aborted"... should that be working? Found this: https://github.com/cpb-/spi-tools and compiled it and ran some tests - it does something. $ sudo spi-config -d /dev/spidev0.0 -q /dev/spidev0.0: mode=0, lsb=0, bits=8, speed=1000000, spiready=0 $ sudo spi-config -d /dev/spidev0.0 -s 500000 $ sudo spi-config -d /dev/spidev0.0 -q /dev/spidev0.0: mode=0, lsb=0, bits=8, speed=1000000, spiready=0 $ sudo spi-config -d /dev/spidev0.0 -s 500000 -w & [1] 2041 $ PID=$! $ sudo spi-config -d /dev/spidev0.0 -q /dev/spidev0.0: mode=0, lsb=0, bits=8, speed=500000, spiready=0 $ sudo kill $PID Note: That 4th test with "-w &" is because of "Note: on some platforms, the speed is reset to a default value when the file descriptor is closed. To avoid this, one can use the -w option that keep the file descriptor open." => Cubietruck is apparently one of those platforms. That's why that speed setting change was only preserved on line $4, not on line $2 Tried looping back as root (sudo su) with spi-pipe (which comes with the spi tools above and the github page says one should be able to do like this) as follows: echo '000' | spi-pipe -d /dev/spidev0.0 | cat - Getting nothing. What am I doing wrong? EDIT 2: found this bug, which suggests there should be some spi0 overlay (?) but that this was missing before 20.02: https://github.com/armbian/build/pull/1663 However, marked as closed / merged as of 20.02 --- so was it closed in 20.02 "current" or "next" which I am running? Shouldn't there be a ...-spi0.dtbo overlay then? Confused.
  22. Hi everyone, I installed the latest version of armbian available today for cubietruck. The volume coming out of the 3.5mm jack is really low. I checked on pulseaudio and the volume is set to maximum. I'm from another distro and didn't have this problem with audio before. Could someone help me? There are other people that have the same issue? Thanks in advance.
  23. Can we get 5.1 sound with hdmi on Cubietruck? Or it's not impossible? (Tried search on Google but no success)
  24. Hello, a few Days ago, i make a new installation on a new SD Card of Buster from here https://www.armbian.com/cubietruck/ on my Cubietruck. Everythink looks fine and run well, but now i have sometimes no connection over ssh to my Cubietruck and the only Think that helps, is to pull the Power Cuble. After i plug it again, everything runs fine a time long..... What can this be? What can i do? Thank you
  25. Is anyone still working with cubietruck? I installed the latest mainline image over Christmas expecting it to have the cedrus driver but apparently it does not. I thought that everything except HDMI audio should be working in mainline now. So I installed the latest legacy image. It plays videos well but bluetooth doesnt work. I switched it on in armbian-config and 'rfkill list' shows it as not disabled but the bluetooth manager shows no adapter and search is grayed out. This is a regression as it used to work to some extent. Also, very importantly for me, neither image switch over to battery power when the AC goes out. This also used to work on legacy, unless it was cubian that worked and armbian never did, I should keep notes...
  • Create New...