CryBaby

I think I already tried linking the old file. I just tried it again and while the loading error is gone otherwise there is no change. Unfortunately this doesn't tell me whether the firmware is wrong or there is some other problem. The github says: I haven't tested the WiFi at all so I'll do that. I see no info on NVRAM for uart based devices.

Well, I have learned something. Disabling the non-functional desktop helps, you can find stuff in the logs now. Firstly: the firmware file. The old page I referenced earlier used the file /lib/firmware/ap6210/bcm20710a1.hcd but in my log it said this: [ 15.336274] bluetooth hci0: Direct firmware load for brcm/BCM20702A1.hcd failed with error -2 [ 15.336285] bluetooth hci0: Falling back to sysfs fallback for: brcm/BCM20702A1.hcd The wrong file is in armbian-firmware, the right file is not. I downloaded one from github and renamed it to match the message. It seemed to load successfully after that. It didn't work though, trouble is there is about 50 files that start with BCM20702A1 and no clue as to the right one. [ 15.104357] Bluetooth: hci0: unexpected event for opcode 0x06c4 [ 25.318761] Bluetooth: hci0: BCM: failed to write update baudrate (-110) [ 25.332570] Bluetooth: hci0: Failed to set baudrate [ 26.926352] Bluetooth: BNEP (Ethernet Emulation) ver 1.3 [ 26.926365] Bluetooth: BNEP filters: protocol multicast [ 26.926393] Bluetooth: BNEP socket layer initialized [ 27.366710] Bluetooth: hci0: command 0x0c03 tx timeout [ 35.558743] Bluetooth: hci0: BCM: Reset failed (-110) [ 35.571171] Bluetooth: hci0: hardware error 0x00 [ 36.742620] ieee80211 phy0: brcmf_p2p_create_p2pdev: timeout occurred [ 36.756228] ieee80211 phy0: brcmf_cfg80211_add_iface: add iface p2p-dev-wlan0 type 10 failed: err=-5 [ 37.606706] Bluetooth: hci0: command 0xfc18 tx timeout [ 45.798600] Bluetooth: hci0: BCM: failed to write update baudrate (-110) [ 45.812862] Bluetooth: hci0: Failed to set baudrate [ 47.846607] Bluetooth: hci0: command 0x0c03 tx timeout [ 56.033010] Bluetooth: hci0: BCM: Reset failed (-110) Secondly: The tty. [ 2.565468] 1c28800.serial: ttyS2 at MMIO 0x1c28800 (irq = 51, base_baud = 1500000) is a U6_16550A [ 2.565660] serial serial0: tty port ttyS2 registered But /dev/ttyS2 no longer exists. Maybe attaching the hci to it is supposed to remove it? Thirdly: uboot/overlays. I have no errors relating to overlays in my uboot output. $ rfkill ID TYPE DEVICE SOFT HARD 0 bluetooth hci0 unblocked unblocked 1 wlan phy0 unblocked unblocked $ bluetoothctl devices No default controller available So, possibly a step closer but not there yet.

Now I'm wondering if the overlays are a red herring. Looking at my /boot none of the ones in joafl's log are there, just a sun7i-a20-cubietruck.dtb which if my reading of boot.cmd is correct, is getting loaded as the default that uboot is falling back to. Also, my armbianEnv.txt has no list of overlays, just a prefix. It looks like I'm going to have to install the kernel sources to get the dt source, which means I'm going to have to expand my filesystem as that did not happen on first run. And connect my cubietruck to a proper monitor so I can see the boot messages and maybe fiddle with uboot. Good job the weekend is coming.

So we shouldn't need to delve into kernel code, just figure out why the overlays aren't loading. Hopefully they already describe the hardware correctly. Unfortunately, uboot is also a bit beyond my ken...

Not sure about detaching. What I have gleaned is that bt.load figures out which tty is attached to uart2 then sends the firmware to it. bt.init resets the chip via a couple of GPIO pins. The systemd service then attaches an hci device to the tty. This is what bluetooth clients use. Now this is all handled by the kernel and I am just assuming that it does pretty much the same thing. In which case not having /dev/ttyS1 is a problem. Using the right GPIOs will also be key. I get the impression that both tty and GPIOs can change between kernels. So we need all the overlays to load (some might provide power etc.) and they need to match the kernel in terms of the tty and GPIO numbers it is expecting. I'm afraid that device tree and kernel code are a little beyond my ken.

I have been following this page: It's out of date but I deduce from it that we should be seeing a tty directory in /sys/devices/platform/soc/1c28800.serial/ Do you have that now?

Same for me on Focal with 5.4.45. I suspect the bluetooth firmware is not being loaded. It is installed with armbian-firmware, the file is bcm20710a1.hcd. It should be sent via uart2 somehow, but it seems there is no tty for it.

I tried Focal: https://dl.armbian.com/cubietruck/nightly/Armbian_20.05.0-trunk.145_Cubietruck_focal_current_5.4.42.img.xz I'll have a go with Bullseye. Update: Bullseye 145 boots but it doesn't resize the filesytem. I went through armbian-config and everything else seems OK. Need more space to try out a desktop though.

I just tried this on my Cubietruck. uBoot doesn't like the initrd image: Verifying Checksum ... Bad Data CRC Disk image is corrupt or invalid Then it tries to load from TFTP. The image sha256sum verified OK and the card mounts on my PC OK.

I suppose my battery may be too old. Unfortunately, a new one would take a couple of months to reach me from China. I'll see if I can source one from Europe. I don't suppose there's an easy way to debug it, when the power goes it dies instantly (twice this week so far). If anyone out there can confirm it works for them that would be good to know. Yes, I contributed to the Kickstarter. Since it was mainlined in the 4.20s I kind of hoped it would be working by now. I guess there's more to it than that, I am vague on the details. I know the legacy image is unsupported, I've been running mainline until recently, but I just got my home theatre set up and I really need my media player to play media. If I could also play games with my bluetooth joystick that would be sweet. I haven't checked the bluetooth on mainline. I'll do that. I do appreciate all your efforts supporting so many devices. So many, and yet none can replace a cubietruck for me...

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...

A reboot fixes it for a while, but it seems after a few recordings the tuner stops sending video data. vdr restarts and apparently reloads the kernel modules to no effect, so it restarts again... It's recording now and I'll do more tests. I downloaded the 5.20 Debian image from the archive with a view to extracting the kernel but 7z errors out before unzipping the whole thing. E_FAIL. That's on the cubietruck. I'll try it on my laptop when I get back to work and have the bandwidth to download it.

Not that I can see. There is nothing for it in /lib/firmware. The syslog does say: dvb-usb: found a 'RTL2832U DVB-T USB DEVICE' in warm state. but there is no mention of firmware.

I have a rtl2838 based DVB-T dongle which was working beautifully under 3.4.112 on my cubietruck. I upgraded a couple of days ago and now I don't get any video data, although the dongle is still recognised. I see 113 includes a fat patch to the rtl2832 driver. Is there some way I can back that out, or a safe way to go back to 112?

My Cubian nand install is using the same old Allwinner u-boot. Unfortunately I am not able easily to test its network performance with big files. My Cubian sdcard install appears to be using whatever came out of the box with the Cubietruck. Presumably it is the same. The network is slow but it never stops. I have noticed that when I initiate scp on my remote armbian Cubietruck (ie. push the files from remote to local) it does not stop. It only stops when I initiate the scp from my local machine (ie. pull). Pushing files from local to remote also does not stop. I haven't had the time yet to try the new u-boot. Presumably I would do a normal nand install then overwrite the old u-boot with the new. Are there instructions for that anywhere?

OK. I have another cubietruck running cubian, which I don't think has the network problem. I will see what it does differently. And I will try the latest mainline u-boot with armbian legacy.

I am booting from NAND as I want the card slot free. v2015.10 has a NAND SPL driver according to http://linux-sunxi.org/Mainline_U-boot. Is that not enough? Or if you build the old u-boot can you include this patch: http://lists.denx.de/pipermail/u-boot/2015-March/209064.html

I'm getting broken connections when I download big files from my Cubietruck. I've tried reducing CPU freq and setting eth0 to 100 half duplex, as recommended in various places. No joy though. It is said that a GMAC fix for this went into u-boot in mid 2015 but my u-boot appears to be older: $ strings /boot/linux/u-boot.bin | grep 201 U-Boot 2011.09-rc1-00000-gc1cb2f9 (May 30 2014 - 10:19:03) Allwinner Technology arm-none-linux-gnueabi-gcc (Sourcery G++ Lite 2010.09-50) 4.5.1 GNU ld (Sourcery G++ Lite 2010.09-50) 2.20.51.20100809 $ cat /etc/armbian-release # PLEASE DO NOT EDIT THIS FILE BOARD=cubietruck BOARD_NAME="Cubietruck" VERSION=5.20 LINUXFAMILY=sun7i BRANCH=default ARCH=arm Is it possible/safe to install a newer u-boot? If so where can I get it? Or perhaps someone can suggest an alternative solution?