count-doku

Members
  • Content Count

    37
  • Joined

  • Last visited

About count-doku

  • Rank
    Advanced Member

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. count-doku

    Clearfog[Pro]mikroBus UART 5V tolerant

    Ok thanks for the info. Was just wondering, because on the mikroBus Header there's also a 5V out. But in the meantime I also measured the voltage on the tx pin of the clearfog and that's at max 3.3V due to pullup resistors. So 3.3V seems like a safe choice. Greetings!
  2. Hi, does anyone know if the provided UART interface on the mikrobus header on the clearfog is 5V tolerant? Greetings, count-doku
  3. count-doku

    read first How to build my own image or kernel?

    I used this as a patch. That enables building of the pcm5102a module. Put it in userpatches/kernel/yourkernel I got the feeling that Kconfig just doesnt show entries without a text in menuconfig. diff --git a/sound/soc/codecs/Kconfig b/sound/soc/codecs/Kconfig index c367d110..87c6ae4c 100644 --- a/sound/soc/codecs/Kconfig +++ b/sound/soc/codecs/Kconfig @@ -680,7 +680,7 @@ config SND_SOC_PCM3168A_SPI select REGMAP_SPI config SND_SOC_PCM5102A - tristate + tristate "Texas Instruments PCM5102A CODEC - I2S" config SND_SOC_PCM512x tristate
  4. count-doku

    testers wanted Testers wanted: sunxi Device Tree overlays

    Yes I am sure that the I2S0 port is enabled, Armbian provides a overlay for that (https://github.com/armbian/build/blob/18215550b367919c1b270185e110b901e2843edd/patch/kernel/sunxi-next/add-sunxi-overlays.patch#L2246-L2276) Which I enabled via Armbian-Config / armbianEnv.txt... Also checked that the device is there using /proc/device-tree/ That is also the reason why I didn't keep the I2S -> Okay Lines from the Raspberry PI overlay. That the driver is normally not included is correct, I will add it and then build my own image. But first I would love to get the device tree overlay working. I will conduct some more testing this afternoon or tomorrow and update this reply with my results. EDIT: So I've got the nodes integrated in the device tree, but not using overlays but decompiling and recompiling it online with dtc. I added the following nodes, maybe someone can create a overlay from that? // under soc sound:sound { compatible="hifiberry,hifiberry-dac"; i2s-controller=<0x99>; // this is taken from above i2s controller, in the overlay there should be a label I guess status="okay"; }; // in the root pcm5102a-codec { #sound-dai-cells = <0>; compatible = "ti,pcm5102a"; status="okay"; }; Testing in /proc revealed the changes had been loaded correctly. Then I tried compiling my own kernel with the PCM5102A driver but the option is not displayed in the kernel configuration. Any ideas? Greetings, count-doku
  5. count-doku

    testers wanted Testers wanted: sunxi Device Tree overlays

    Hi, I have the Banana Pi M1 and the Banana Pro and just received a I2S to Analogue Module. I'd love to use these together but unfortunately there is no device tree overlay available. The module is from Adafruit (https://learn.adafruit.com/adafruit-i2s-stereo-decoder-uda1334a) they also mention it is the same chip / driver that is also used by the Hifiberry DAC, there is support for Raspbian also with an overlay etc. (see the Raspberry PI kernel tree | https://github.com/raspberrypi/linux/blob/rpi-4.14.y/arch/arm/boot/dts/overlays/hifiberry-dac-overlay.dts). I tried adapting the overlay for usage with the Banana but didn't get it running. So any help would be greatly appreciated, I will then of course test and report. Also have a uart to usb cable to access uboot and can build images. This is what I have so far: /dts-v1/; /plugin/; / { compatible = "allwinner,sun7i-a20"; fragment@0 { target-path = "/"; __overlay__ { pcm5102a-codec { #sound-dai-cells = <0>; compatible = "ti,pcm5102a"; status = "okay"; }; }; }; fragment@1 { target = "/soc@01c00000"; __overlay__ { sound: sound { compatible = "hifiberry,hifiberry-dac"; i2s-controller = <&i2s0>; status = "okay"; }; }; }; }; Of course using above overlay and enabled I2S0 Port already with Armbian-Config / armbianEnv.txt and the provided overlay. Naturally there is a driver / codec required to get the Sound Module working, but I think we could use the driver from the Raspbian Kernel Source: https://github.com/raspberrypi/linux/blob/rpi-4.14.y/sound/soc/codecs/pcm5102a.c Doesn't seem to rely on anything raspberry specific. I would integrate, test and the do a PR on github, with this stuff, but need some help getting the overlay working first. Greetings, Count-Doku
  6. As there were no answers I suspect most people run of the sdcard / mmc anyways, or manually moving u-boot into place after an update does not bother them. So I wrote a small update code for myself (see below), feel free to use it. #!/bin/bash DIR=/usr/lib/linux-u-boot-next-clearfogpro_5.60_armhf VARIANT=u-boot.mmc DEVICE=/dev/mmcblk2 if [ -b $DEVICE ]; then echo "Writing u-boot to default location..." dd if=$DIR/$VARIANT of=$DEVICE bs=512 seek=1 status=noxfer echo "Completed!" exit 1; else echo 'Could not write the default uboot to mmc/sdcard ' read -p 'Please enter uboot variant to install: mmc, sd, sata, flash > ' VARIANT case $VARIANT in mmc|MMC|sd|SD) VARIANT=u-boot.mmc ;; sata|SATA) VARIANT=u-boot.sata ;; flash|FLASH) VARIANT=u-boot.flash ;; *) echo 'Invalid variant, aborting.' exit 0 ;; esac read -p 'Enter boot device (eg. /dev/mmcblk2) > ' DEVICE if [ ! -b $DEVICE ]; then echo "Device not available, aborting!" exit 0; fi echo '' echo 'U-Boot Path: ' $DIR echo 'Will now try to write ' $VARIANT ' to ' $DEVICE read -p 'Start writing? (yes/no)' START if [ $START == "yes" ]; then echo "Writing..." dd if=$DIR/$VARIANT of=$DEVICE bs=512 seek=1 status=noxfer echo "Completed!" exit 1 fi fi Of course things like the U-Boot Directory change and need to be adjusted. It could also be called as a parameter. I am unsure if it is possible to integrate that into Armbian as I could not find out, where the related linux-u-boot-clearfogpro-next.deb Packages gets build / comes from. Greetings, count-doku
  7. Hi, I updated my ClearfogPro today and noticed (that like in the last updates), updating the linux-u-boot-clearfogpro-next package fails, with the error "/dev/mmcblk2" doesn't exist". This happen obviously, because I don't have a SD Card installed, as I am using a M.2 SSD to boot and as root. Quick check inside the .deb file revealed the platform_install.sh which only tries writing the u-boot.mmc version to /dev/mmcblk2. For me this is not a big problem, I know how to get the correct u-boot into place (/usr/lib/linux-u-boot-next-clearfogpro_5.60_armhf/u-boot.sata) but new users might find it difficult. Would it be possible to let the users select the device for writing the u-boot when the mmc variant fails? Just a popup with a text saying: "Could not write u-boot to default location (sdcard/mmc), please specify device" and a textbox below... (Might even look into doing something like this myself and then send a PR) Or does Armbian normally keep track of where the u-boot is and I just did something wrong when moving from sdcard to ssd? Greetings, count-doku EDIT: Just realised this might apply to other boards to, if it would better fit into Development or so, please move.
  8. count-doku

    clearfogpro plug fan

    Yes you could use the Pins from the mikrobus header but make sure your fan does not draw to much power for the 5V regulator. If it is a 12V fan you could also run it directly on your input (if this is 12V). There are some headers near the power plug which can be used with a small adapter. I attached an image which highlights the connectors. Check https://wiki.solid-run.com/lib/exe/fetch.php?media=a38x:carrierboard:docs:clearfog-schematics-2.1.pdf for the schematics. The power regulators etc are on page 13... EDIT: looks like the power regulator for 5V is the RT2875A/B which can source up to 3A. Greetings
  9. count-doku

    Clearfog pro network : make a gateway

    Answer to question 1: Yes eth0 goes to the isp box. And br0 to my network. But I forward my global ipv4 from the isp box directly so they are not the same network. Internet ---- ISP Box (Modem) ------ Clearfog -------- br0 ------ lan1-6 77.11.22.33 192.168.1.1 \-- wlan So the clearfog is directly connected with the internet and the isp box is a completely transparent ethernet / dsl bridge. --- Answer to second question: yes they are configured manually. The auto stanza only means the interfaces get ifup'ed automatically. The actual lan ports (1-6) don't get IPs themselves. They only got MAC Addresses (like a switch). Only the br0 interfaces has a local ip (192.168.1.1). Then all packets from lan1-6 go over the br0 interface. All the routing etc. is based on that. Greetings
  10. Ok then I wont worry about my temps. Stable at 45°C. Thanks.
  11. count-doku

    Clearfog pro network : make a gateway

    Hi as a matter of fact I'm running a similar configuration except that my clearfog does also provide dns / dhcp. And is in an different network to the isp box. Yes a network bridge is what you've got to do. But it depends if you're using NetworkManager or plain interfaces file and which program for the wifi host. I'd suggest using iptables, ifupdown and hostapd to do what you want. Maybe throw in dnsmasq for dns resolve and dhcp depending if you want it or not. Using the packet names you can get alot of info online, tipp also google for stuff like raspberry pi router (there are many good example for that crap piece of hardware). I also attached my config as reference to this post, maybe check them. But be warned they can't be used 1:1. Greetings, count-doku ... In my configuration using hostapd (Wlan), ifupdown (Interfaces) and iptables a sample configuration could look like this: ( note file name included in top row) root@clearfogpro:~# nano /etc/network/interfaces Nano: auto lo # Autoup the external isp facing interface eth0 auto eth0 # Autoup first the switch port, then the subsystem lan ports and last the bridge auto eth1 lan1 lan2 lan3 lan4 lan5 lan6 br0 iface lo inet loopback allow-hotplug eth0 # Use eth0 for ipv4/6 with dhcp, restore iptables from file on up iface eth0 inet dhcp post-up # !!! Call ip tables init file here. Check online on different ways (if-up.d folder) # Configure eth1 (switch) as manual eg. no ip4 only linklocal ipv6, goes up through auto up iface eth1 inet manual # Disables eth2 (sfp) iface eth2 inet manual # Configure all lans as manual (go up through auto up) iface lan1 inet manual iface lan2 inet manual iface lan3 inet manual iface lan4 inet manual iface lan5 inet manual iface lan6 inet manual # Configure the bridge, give bridge_ports and configure adress etc. iface br0 inet static bridge_ports lan1 lan2 lan3 lan4 lan5 lan6 address 192.168.1.1 netmask 255.255.255.0 network 192.168.1.0 broadcast 192.168.1.255 root@clearfogpro:~# nano /etc/hostapd.conf Nano: interface=wlp2s0 bridge=br0 # This adds the wifi port to our bridge defined in /etc/network/interfaces driver=nl80211 [...] More configuration for ssid and settings following. I cut them out - but there are plenty hostapd tutorials out there... root@clearfogpro:~# nano iptables-conf/iptables.user.conf Nano: #!/bin/sh PATH='/sbin' ### INIT ### # Flush previous rules, delete chains and reset counters iptables -F iptables -X iptables -Z iptables -t nat -F # Default policies iptables -P INPUT DROP iptables -P OUTPUT DROP iptables -P FORWARD DROP # Enable kernel settings for ip forwarding and some other related entries. This can also be fixed echo -n '1' > /proc/sys/net/ipv4/ip_forward echo -n '0' > /proc/sys/net/ipv4/conf/all/accept_source_route echo -n '0' > /proc/sys/net/ipv4/conf/all/accept_redirects echo -n '1' > /proc/sys/net/ipv4/icmp_echo_ignore_broadcasts echo -n '1' > /proc/sys/net/ipv4/icmp_ignore_bogus_error_responses #echo -n '1' > /proc/sys/net/ipv6/conf/all/forwarding #echo -n '2' > /proc/sys/net/ipv6/conf/eth0/accept_ra # Enable loopback traffic iptables -A INPUT -i lo -j ACCEPT iptables -A OUTPUT -o lo -j ACCEPT # Enable statefull rules (after that, only need to allow NEW conections) iptables -A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT iptables -A OUTPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT iptables -A FORWARD -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT # Drop invalid state packets iptables -A INPUT -m conntrack --ctstate INVALID -j DROP iptables -A OUTPUT -m conntrack --ctstate INVALID -j DROP iptables -A FORWARD -m conntrack --ctstate INVALID -j DROP ##################################################################################################################### ### nat - PREROUTING ### ##################################################################################################################### ### filter - INPUT ### # Allow incoming icmp iptables -A INPUT -p icmp -m conntrack --ctstate NEW -j ACCEPT # Allow all incoming traffic from local area network interface iptables -A INPUT -i br0 -m conntrack --ctstate NEW -j ACCEPT ##################################################################################################################### ### filter - OUTPUT ### # Enable all outgoing traffic to internet iptables -A OUTPUT -o eth0 -d 0.0.0.0/0 -m conntrack --ctstate NEW -j ACCEPT # Enable access traffic, from the firewall to the LAN network only in valid ip range iptables -A OUTPUT -o br0 -d 192.168.1.0/24 -m conntrack --ctstate NEW -j ACCEPT ##################################################################################################################### ### filter - FORWARD ### # Forward packages from the internal network (br0) to the internet (eth0) iptables -A FORWARD -i br0 -o eth0 -s 192.168.1.0/24 \ -m conntrack --ctstate NEW -j ACCEPT ##################################################################################################################### ### nat - POSTROUTING ### # Masquerade packets going into the internet (eth0) iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE ##################################################################################################################### ## LOGGING #iptables -A INPUT -j LOG --log-level DEBUG --log-prefix '[FW INPUT]: ' #iptables -A OUTPUT -j LOG --log-level DEBUG --log-prefix '[FW OUTPUT]: ' #iptables -A FORWARD -j LOG --log-level DEBUG --log-prefix '[FW FORWARD ]: '
  12. Out of interest, which temperature is your m.2 ssd idling at? You can check with: :> apt install smartmontools :> smartctl -a /dev/sda # Replace sda with your m.2 device Then check for the value at id 194. Example output: ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE UPDATED WHEN_FAILED RAW_VALUE 194 Temperature_Celsius 0x0002 100 100 000 Old_age Always - 45 Raw value contains actual temperature. I thought mine was relatively hi but maybe it is just bc it is placed under the cpu.... Maybe Technicavolous extender would be a good idea to move it a bit away from the board. Greetings
  13. There is a perfect guide for installing to M.2 SSD available here: https://github.com/nightseas/arm_applications/blob/master/doc/getting_started_with_clearfog_base.md Bottom page comes the M.2 SSD part. If you want to make use of your existing setup on the sd card, just use another device (eg. computer) to make an img of the sd and then write it to the m2. Just remember flashing the new uboot to the m2 disk. But thats also described in above article. I recently used it to port everything from sd to m.2 ssd and it works like a charm. The sd card ain't even neccessary to boot.
  14. count-doku

    Clearfog[Pro] I²C Devices

    Ah ok thats why I couldnt really talk to the device. Thanks
  15. Hi, out of interest I was checking the I²C Devices connected to the ClearfogPro. So this is thought as a small guide to the i2c bus. The second i2c bus goes straight to the mikrobus/click header so there is nothing on default. --- i2cdetect for bus 0 gave me: 0 1 2 3 4 5 6 7 8 9 a b c d e f 00: -- -- -- -- -- -- -- -- -- -- -- -- -- 10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 20: UU -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 40: -- -- -- -- -- -- -- -- -- -- -- -- 4c -- -- -- 50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 60: -- -- -- -- 64 -- -- -- -- -- -- -- -- -- -- -- 70: -- -- -- -- -- -- -- -- Device 0x20 ) After checking the device tree and schematics, the device at 0x20 is the IO Expander used by a driver. Device 0x4c ) The 0x4c device is also listed in the dt. As the AD Converter for mikrobus/click header. I confirmed this working. You can use this, to read the current value. i2cget 0 0x4c 0x99 w 0x4c is the bus address. 0x99 is the data address according to the MCP3021 datasheet, w means we want to get a word. It then returns the current value, which can be interpreted by using the formula from the datasheet. Device 0x64 ) I don't know what is on the bus here. Neither the datasheet nor the device tree mentions anything, does anyone know? --- I2C Flash 24AA025UID ) The datasheet mentions the flash chip is only assembled in DNP assembly (checked not on my board) so this device is not available. I hope this helps someone else understand how to use the analog input pin and maybe give me a hint whats at 0x64. Greetings, count-doku