• Posts

  • Joined

  • Last visited

Profile Information

  • Gender
  • Location
    Sydney, AUS

Recent Profile Visitors

1003 profile views

phelum's Achievements

  1. After my failed experiment with the 5.10 kernel I downloaded the source to the Armbian 5.8.16 kernel. It works well and the extra for the AXP209 driver (charge RTC battery) is good. I still can't get ttyS2 to work with the new DTB so I'm sticking to the 4.19.62 DTB for the moment. Cheers, Steven
  2. Well, only to an extent. I can now load the firmware into the AP6210 but Bluetooth seems dead. "hcitool dev" shows the hci0 device but "hcitool scan" won't detect any other bluetooth devices. Also, "hcitool scan" on other devices dosen't detect this CT. I've also played with linux-5.10.0 from because the source is available. But the HDMI display doesn't work (sun4i-drm can't open pipelines) and syslog is reporting that the build_platform code causes an error apparently trying to get the name for IRQ 0 (not a valid IRQ). Bluetooth results are consistent with the 5.8.16 kernel (i.e. depends on which DTB I use). Is the source for the 4.19.62-sunxi kernel available ? Thanks, Steven
  3. Thanks for the reply. I decompiled and compared. The newer DTB has a "bluetooth" stanza in the uart2 stanza. I've now downloaded the current release (5.10) and the DTB from it has the uart2.bluetooth stanza and UART2 doesn't work. But if I remove the stanza from the DTS then the resultant DTB does work. I don't need the Armbian enable_uart2 overlay or the param_uart2_ctsrts. I suppose the next step is to find out why the uart2.bluetooth stanza confuses the kernel so it doesn't create the device correctly. Viewing /proc/interrupts and /sys/class/tty/ttyS2 shows things aren't quite right. Thanks, Steven
  4. 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
  5. Thanks for the reply. I still have the old git that does work with the legacy kernels. The current git might work if I add the required scripts to the extra configs. I'll report if I get it working. Cheers, Steven
  6. Hi, Can anybody tell me where to find the source for the A20 NAND U-boot found in the Armbian Cubietruck releases ? I've been using an old copy of the linux-sunxi u-boot git. I've recently updated it but the config in the lichee-dev-a20 branch seems to be for Android only and has no provision to load boot.scr. Thanks, Steven
  7. phelum


  8. Hi, I've managed to get BT working with Armbian stretch on my Cubietruck. But I had to modify the .dtb to get the CT_Bluetooth patch to work. I'll download the buster release and see if I can get BT to work. I've uploaded my relevant files to One possibly relevant fact is that I'm using /sbin/init rather than systemd here. I've just tested with buster (5.7.15) and find I must use the 4.19.62 dtb and set /etc/bluetooth/uart to /dev/ttyS2. Then my bt-load script can load the firmware into the device and bluetooth works somewhat. I'm using the old 4.99 bluetooth release. So I think my code for loading the device is okay in this new environment. Can anybody get the current bluez release to work with a uart device as opposed to a USB device ? I can establish a serial link to other devices but can't get DUN to work because wvdial times out while I'm entering the PIN on my phone. Cheers, Steven
  9. Hi, I suspect you'll need a special version of u-boot and I don't know if such a version exists. The NAND boot process requires boot0 in blocks 0 and 1, and boot1 in blocks 2 to 7, and the kernel and u-boot-bin in the first partition. The MBR and partitions are all in the "logical" section of NAND which is after the reserved (maybe 12) blocks in NAND. The blocks in this logical section aren't necessarily where they appear to be due to bad block relocation and wear levelling. The problem I see with booting from NAND is that unless you have a kernel that can access the NAND then you will have the situation where you can't update your kernel. So I stick to the old 3.4 kernel for my NAND boot systems but I'm stuck with running wheezy here and this is becoming a major disadvantage. The good thing about an SD-card is that if it packs up it's easy to replace. Maybe it is the better option. However, if there is a u-boot-bin version that will load the kernel from NAND then maybe it's worth a try. This would help if the onboard SD card reader packs up. Cheers, Steven
  10. Hi, I'm trying to create a DT overlay for my Cubietruck running 4.19.62 and I've placed it in /boot/overlay-user and changed the user_overlays entry in boot.scr to load it. It is being loaded but I'm getting FDT_ERR_NOTFOUND when trying to apply it. The overlay is meant to change the label and default-trigger entries for the four LEDs in the leds node. I'm using dtc 4.1.4 and it does compile this overlay. Can anybody tell me how I can change this overlay so it will work ? Or perhaps tell me if this is not possible. /dts-v1/; /plugin/; / { compatible = "allwinner,sun7i-a20"; fragment@0 { target = <&leds>; __overlay__ { blue { label = "blue"; linux,default-trigger = "heartbeat"; }; orange { label = "orange"; linux,default-trigger = "cpu0"; }; white { label = "white"; linux,default-trigger = "cpu1"; }; green { label = "green"; linux,default-trigger = "mmc0"; }; }; }; }; Thanks, Steven
  11. Hi, DNS would be difficult because the hosts on this local network have dynamic addresses. This is why nmbd (part of the Samba suite) is good and it works fine on hosts running wheezy or jessie (or Windows). There is an option called "socket options" in smb.conf and I've tried setting SO_RTIMEO (receive timeout) but it doesn't have any effect. The host running stretch can use ssh <other host name> to connect to any other host but other hosts find it very difficult to use ssh <stretch host name> to connect to the stretch host. I'll try running wireshark to see if the stretch host is getting the broadcast and if it is replying. As I said, the timeout seems very short. Cheers, Steven
  12. The resultant file is like a devicetree file in that it contains hardware details. Old kernels use this to get the addresses of devices for instance. So it's mainly used by the kernel. Some U-Boots have 'script_parser_fetch' code which means that the U-Boot is also accessing details from the file. Cheers, Steven
  13. Hi, I'm using NetBIOS names when using ssh to access other CTs on my local network. Most of the CTs and other hosts are running Wheezy. Now I have a CT running Stretch and it's very difficult to access this host using 'ssh <stretch host name>' because it's not responding to the broadcas from the calling host. If I repeat the request (and broadcast for the name) multiple times then sooner or later the Stretch CT will respond in time. The timeout on the host doing the broadcast seems very short. Does anybody know where this timeout is specified and how to change it ? Thanks, Steven
  14. &amp;nbsp; &amp;nbsp;Hi, I bought a TK1 because it runs real OpenGL. I have managed to get it running with my CubieTruck system (Debian) and the NVidia kernel. The major hassle was getting the NVidia driver to work. So it definitely can be done and the video driver was the only bit that took some work. I'm running Wheezy and I haven't tried a Jessie system. The NAND setup is way different from Cubie boards. On the TK1 the NAND is /dev/mmcblk0 and the boot files are in the /boot directory. Cheers, Steven
  15. Hi Igor, I built U-Boot from and selected the sunxi branch and used the standard defconfigs (Cubieboard_config, Cubieboard2_config, and Cubietruck_config). I haven't patched or changed anything. Cheers, Steven