usual user

August 7, 2020

11 hours ago, laurentppol said:

Is this "simple Makefile" project? Can be found by google?

You followed the link in the first post about tmon and looked around the directory where the README is located?

August 5, 2020

The tool is part of the kernel source tree. I don't know how it's packed in your environment but following the README it can be built very easily in the appropriate directory. If not packed for Armbian perhaps a good opportunity to contribute by PR to Armbian.

August 3, 2020

4 hours ago, laurentppol said:

Someone knows how to get core temperature (like on ssh login screen & htop screen) from shell command line?

Use "tmon -dl".

August 2, 2020

On 8/2/2020 at 4:31 PM, David12412412 said:

3.3V --------> Push Button ------->1k Resistor ------> PA19

Error prone HW design with floating IO.
Proper design with fixed IO states:

VCC --------> Pullup Resistor ---|
GND --------> Push Button -------+------> PA19

The pullup is already in place.
Pressing the button will flip the IO from 1 to 0.

July 27, 2020

14 hours ago, CryBaby said:

And it seems to be using it.

According to your log, which I quoted in my previous post, it was not. Hence my request for the version verify.

The wifi kernel driver loads any code that is in the outlined location, and as long as you have not "ln --symbolic /lib/firmware/ap6210/fw_bcm40181a2.bin /lib/firmware/brcm/brcmfmac43362-sdio.bin" and "ln --symbolic /lib/firmware/ap6210/nvram.txt /lib/firmware/brcm/brcmfmac43362-sdio.cubietech,cubietruck.txt" in place, it won't use the desired ones.
You can also copy over the code, but I prefer the symlink method if I have to differ from the mainline linux-firmware code. If a mainline linux-firmware update breaks in an incompatible way, I only lose the symlinks and recreating them again restores the functionality.

10 hours ago, CryBaby said:

Also, none of the 54 hcd files from github match ap6210/bcm20710a1.hcd

Since these are firmwares for USB host interface attached chips, we are dealing with the UART host interface.

July 23, 2020

5 hours ago, CryBaby said:

BCM43362/1 wl0: Mar 10 2014 14:59:50 version 5.90.195.89.18 FWID 01-b13c09c7

Because "strings ap6210/fw_bcm40181a2.bin | grep 43362" gives me "43362a2-roml/sdio-g-pno-pktfilter-keepalive-wapi-wme-p2p-*unknown* Version: 5.90.195.0 CRC: b99a439d Date: Mon 2014-03-10 15:00:57 CST", I wonder if you have another one or do not use it. The kernel driver is expecting it as /lib/firmware/brcm/brcmfmac43362-sdio.bin for loading. And its companion nvram as brcmfmac43362-sdio.cubietech,cubietruck.txt. If not available it will fall back to brcmfmac43362-sdio.txt.
Wifi and bluetooth have to cooperate because they share at least the same antenna in your design.

5 hours ago, CryBaby said:

Looking at the service file it seems I shouldn't have to link the hcd. Hmm.

Where user space tools expect and name their resources is a completely different story.

July 22, 2020

The dtb change was to test if there was some issue with the shutdown gpio. Without that it is relying on the power on reset, i.e. a non working warm boot is expected.
It looks like as soon as the BT firmware got loaded, the BT chip stops working. My research has shown that the files in ap6210/ are the ones that were also used with the old user space load method. Therefore, they should be right and work. Maybe it is worth to revert back to the old method and try if this still works. To do this, remove the entire bluetooth {...}; node from the dtb. This way the kernel driver will no longer touch bluetooth and the old method (brcm_patchram_plus, hciattach, ...) should be usable again.
What me puzzles is with which hardware we are here really dealing. The referenced cubietruck documentation claims it has an AP6210 with a BCM20710. But the initial firmware announces it as BCM20702A and despite the name ap6210/bcm20710a1.hcd, it contains this string: "BCM20702A1 Generic UART Class 1 @ 26 MHz".

July 20, 2020

Studying the provided logs gives some clues.
After a fresh install I guess there are /lib/firmware/brcm/brcmfmac43362-sdio.bin and /lib/firmware/brcm/brcmfmac43362-sdio.bin.txt in place.
With this, the wifi driver get loaded and with no /lib/firmware/brcm/BCM20702A1.hcd no BT firmware upload does take place. The embedded BT firmware in brcmfmac43362-sdio.bin get used and the BT host interface via uart is working. Because the embedded firmware most probably does not match the BT hardware it has to be updated by BCM20702A1.hcd for proper operation.
So we are back to find out why this is failing.
The only relevant binding in the DT is this line:

shutdown-gpios = <&pio 7 18 GPIO_ACTIVE_HIGH>; /* PH18 */

For a test let us remove it from the dtb.
Copy the original sun7i-a20-cubietruck.dtb to sun7i-a20-cubietruck.dtb.orig at your workbench. Disassemble the dtb (dtc -I dtb sun7i-a20-cubietruck.dtb.orig > sun7i-a20-cubietruck.dts). Use your preferred text editor to remove the "shutdown-gpios = ..." line at the bluetooth node in the sun7i-a20-cubietruck.dts. Compile the dtb again (dtc -I dts sun7i-a20-cubietruck.dts > sun7i-a20-cubietruck.dts) Now replace sun7i-a20-cubietruck.dtb at the boot location with this one and reboot.
This should now be able to upload BCM20702A1.hcd and make BT working to some extent. Since there is no longer any way to reset the BT, this only works after a power cycle, a warm reboot fails.

Can you also try the wifi firmware in /lib/firmware/ap6210/ as described above? Because the version has a newer time stamp (date: Mon 2014-03-10 15:00:57 CST) than the firmware you are using.

Now that I know the board specific nvram name I just discovered linux-firmware is already carrying a brcmfmac43362-sdio.cubietech,cubietruck.txt. It is identical to the nvram_ap6210.txt except the "macaddr=" parameter.
But also the brcmfmac43362-sdio.bin has a newer time stamp (Date: Wed 2018-05-16 23:44:07 CDT). Maybe this one is worth a try also.

July 19, 2020

Just out of curiosity I took a look at the ap6210 directory on my NanoPC-T4 image:

ap6210/bcm20710a1.hcd
ap6210/bd_addr.txt
ap6210/fw_bcm40181a2_apsta.bin
ap6210/fw_bcm40181a2.bin
ap6210/fw_bcm40181a2_p2p.bin
ap6210/nvram_ap6210.txt
ap6210/nvram_apxxxx.txt
ap6210/nvram.txt

I see they are not only carrying the bluetooth firmware but also wifi firmware and its companion nvram.
I don't know where your used ones are origination from but to rule out this special versions are required,
let's put them in place.
Temporarily rename /lib/firmware/brcm/brcmfmac43362-sdio.bin and create a symlink
(ln --symbolic /lib/firmware/ap6210/fw_bcm40181a2.bin /lib/firmware/brcm/brcmfmac43362-sdio.bin).
I don't know if you're using only the generic name (brcmfmac43362-sdio.bin.txt) for nvram.

If so, let's do it the proper way.
1. Temporarily rename /lib/firmware/brcm/brcmfmac43362-sdio.bin.txt
2. Reboot and check dmesg for which <nvram>.txt is being searched.

First attempt will try a board specific one, second attempt will try brcmfmac43362-sdio.bin.txt. We are interested in the name of the board specific one.
Copy over ap6210/nvram.txt to /lib/firmware/brcm/brcmfmac4356-sdio.<specific name>.txt

With board specific name at least one <nvram>.txt for each board can coexist in the searched directory. And yes, in theory, every board needs a specific one. Falling back to the generic can work, but can break as soon as the generic one changes. One doesn't fit them all.
Now reboot and check if this has changed anything regarding Bluetooth.

July 19, 2020

I agree with your analysis, something goes wrong with the hci initialization.
What worries me are these lines:

16 hours ago, CryBaby said:

[ 16.742840] Bluetooth: hci0: command 0xfc18 tx timeout

[ 24.806758] Bluetooth: hci0: BCM: failed to write update baudrate (-110)

[ 24.806771] Bluetooth: hci0: Failed to set baudrate

Since the driver already works in many other situations, my suspicion is again focused on the board-specific configuration.
Just to rule this out, there are no more user space services (with brcm_patchram_plus, hciattach, ...) that might conflict (e.g do some reset) with kernel-mode hci initialization? They are no longer needed with the new mode.
Because the user space tools did not rely on the bluetooth DT node (they did there own thing) maybe there is still something not set up properly.

Oh, one more idea, can you boot without any overlays. To rule out they make bluetooth non working by pull conflicting configuration.

16 hours ago, CryBaby said:

What is missing is the lines github says indicate a successful firmware load:

With "strings bcm20710a1.hcd | grep BCM" you can check which version string to expect.

July 18, 2020

2 hours ago, CryBaby said:

Unfortunately this doesn't tell me whether the firmware is wrong

The firmware is probably for your device. If it is wrong for you, it may be missing a feature that you expect.
Anyway, the basic functionality should be present so bluetooth starts working.

Because the wifi and the bluetooth component share some hardware resources on the module both kernel drivers have to be loaded properly. User space does not need to use the WiFi component, but the WiFi kernel driver must be ready to let Bluetooth work.

2 hours ago, CryBaby said:

I see no info on NVRAM for uart based devices.

The Wifi component is attached via sdio and the driver will request the firmware and the nvram like the bluetooth driver.
Look at the output of "dmesg" after boot up to see if something is missing.

July 18, 2020

5 hours ago, CryBaby said:

The old page I referenced earlier

This post uses the outdated method of uploading the firmware via an user space tool. To have access to the bluetooth device it needs /dev/ttyS# for the communication. Further the firmware file name is given as a parameter so you can throw in any arbitrary name.
The new method of uploading the firmware via the kernel driver has no way to use an arbitrary name. Because the driver is used for several BCM chips it can only use some generic name (brcm/BCM20702A1.hcd). Since the previously used bcm20710a1.hcd was apparently the right one, a symbolic link (ln --symbolic /lib/firmware/ap6210/bcm20710a1.hcd /lib/firmware/brcm/BCM20702A1.hcd) would be sufficient to continue using it.

5 hours ago, CryBaby said:

Secondly: The tty.

Having no /dev/ttyS# is ok, the kernel driver is now dealing with the uart2 and making it accessible
to the user via /dev/ttyS# can even be dangerous as it can affect driver operation.

July 17, 2020

1 hour ago, CryBaby said:

Now I'm wondering if the overlays are a red herring.

All permanently equipped components on a device should be represented in the base dtb. Overlays are for optional components. Think of something connected via gpio-connector or a camara module via csi-connector. Because the configuration may clash or if an option is not applied, it is not desirable to have them in the base dtb. So if no addons are used the base dtb should suffice.

1 hour ago, CryBaby said:

It looks like I'm going to have to install the kernel sources to get the dt source

If you are interested in mainline, https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree should suffice. And don't look too closely, it already has the Bluetooth node since a while I see no vbat-supply and vddio-supply bindings in there. But I don't know if they are required for your device.
I see this:

Quote

5197 [ 10.572239] hci_uart_bcm serial0-0: serial0-0 supply vbat not found, using dummy regulator
5198 [ 10.572369] hci_uart_bcm serial0-0: serial0-0 supply vddio not found, using dummy regulator

in the logs. It may be normal but the real regulators may be not enabled by power management (no consumers).
Maybe adding the bindings is the missing part, but I don't really know.

July 17, 2020

1 hour ago, CryBaby said:

Hopefully they already describe the hardware correctly.

Because the driver searches for the Bluetooth node, simply check that your device tree has such a node.
This is the one of my device:

&uart0 {
    pinctrl-names = "default";
    pinctrl-0 = <&uart0_xfer &uart0_rts &uart0_cts>;
    status = "okay";

        bluetooth {
                compatible = "brcm,bcm43438-bt";
                clocks = <&rk808 1>;
                clock-names = "lpo";
                device-wakeup-gpios = <&gpio2 RK_PD2 GPIO_ACTIVE_HIGH>;
                host-wakeup-gpios = <&gpio0 RK_PA4 GPIO_ACTIVE_HIGH>;
                shutdown-gpios = <&gpio0 RK_PB1 GPIO_ACTIVE_HIGH>;
                max-speed = <4000000>;
                pinctrl-names = "default";
                pinctrl-0 = <&bt_reg_on_h &bt_host_wake_l &bt_wake_l>;
                vbat-supply = <&vcc3v3_sys>;
                vddio-supply = <&vcc_1v8>;
        };
};

It showcase only what you are looking for. Because I have a completely different board and different BCM chip the values don't match for your board. Even the required bindings may vary (see the already referenced binding doc). But it will use the same driver in the end.

1 hour ago, CryBaby said:

Unfortunately, uboot is also a bit beyond my ken...

The only task of uboot is to initialize the system so that the boot device can be accessed. Then it loads the kernel and its companion data (dtb, initramfs, ...) and transfers control to the kernel. Since this already works, you don't have to worry about it. By the way, mainline uboot is using the same DT files while its build as the kernel uses, but requires only few DT nodes for its operation. And bluetooth isn't one of it, uboot has no business in bluetooth

July 17, 2020

1 hour ago, CryBaby said:

I'm afraid that device tree and kernel code are a little beyond my ken.

Device tree is describing the hardware design of a device that can't be auto detected.
You probably missing a proper bluetooth DT node. It will tell the kernel which driver to load and the driver will know how the chip is wired and which firmware to load to operate the device. This is used to use the same driver for a particular chip, regardless of how it is wired and what possible configuration parameters it needs. Figuring the proper values for your specific board is the hard part if no DT node is already provided. But once it's done, it won't change unless you change your hardware design.

July 16, 2020

For my NanoPC-T4, I want to be able to install multiple kernel versions at the same time and boot a specific one by default. In addition, I would like to be able to select which kernel to start if necessary:

Armbian_20.07_Arm-64_focal_dev Boot Options.
1:      linux-default
2:      5.8.0-rc4-arm-64
3:      5.8.0-rc3-arm-64
4:      5.8.0-rc2-arm-64
5:      5.8.0-rc1-arm-64
6:      linux-test

To present my solution, I have used "Armbian_20.07_Arm-64_focal_dev_5.8.0-rc4.img.xz" and "u-boot-rk3399-nanopc-t4.img 07/10/2020 8:50am" on a microSD:

Spoiler

With Armbian_20.07_Arm-64_focal_dev_5.8.0-rc4 running:

First step: prepare kernel versions


cd /usr/lib/modules/5.8.0-rc4-arm-64"
cp --preserve --recursive /boot/dtb ."
cp --preserve /boot/System* .
cp --preserve /boot/config* .
cp --preserve /boot/zImage .

For other kernel versions prepare /usr/lib/modules/<kernel-version> in a similar way in other images and copy /usr/lib/modules/<kernel-version> over.

Second step: prepare for dristro-boot


mkdir /extlinux

Copy the attached extlinux.conf into /extlinux/extlinux.conf over.

extlinux.conf

The single image dependent value is PARTUUID, "9df910cf" is the one setup by "u-boot-rk3399-nanopc-t4.img 07/10/2020 8:50am". If you are using a different MBR use "blkid" to check out and adjust appropriatly.

"ln --symbolic 5.8.0-rc4-arm-64 /usr/lib/modules/linux-default" will determine which kernel will be used by 1: linux-default.
"ln --symbolic 5.8.0-rc5-arm-64 /usr/lib/modules/linux-test" is for convenience to pull in e.g. 5.8.0-rc5-arm-64 by 6: linux-test.
So flipping linux-default/linux-test changes the used kernel without further intervention.

Third step: activate distro-boot
Inform uboot to search at the second partition for its configuration:


fdisk /dev/mmcblk1

Welcome to fdisk (util-linux 2.34).
Changes will remain in memory only, until you decide to write them.
Be careful before using the write command.

Command (m for help): a
Partition number (1,2, default 2): 2

The bootable flag on partition 2 is enabled now.

Command (m for help): w
The partition table has been altered.
Syncing disks.

Reboot and use distro-boot.

All copied files do not interfere with the old boot scheme and can coexist. The content of the /usr/lib/modules/<kernel-version> directory is rootfs agnostic, i. e. it can be used in any image where the kernel fit the device. It is even working with Fedora userspace for me. The old boot scheme can be reactivated by disabling the boot flag again (redo third step).

With this scheme in place I am able to pull in a new kernel without the need to port over my local image configuration to a new image. If the new kernel is not working as expected all previous available ones are just a reboot away. If the new kernel version is suitable for boot on demand just a new boot stanza in extlinux.conf is nessesary.

The mainline uboot for NanoPC-T4 has not yet enabled USB keyboard support. Therefor the on demand selection of a boot option will only work via the serial console keyboard.

The build of uboot with the same options in nanopc-t4-rk3399_defconfig as it was done for Pinebook Pro and rockpro64, should probably enable it in a similar way. This means that only HDMI display and USB keyboard are required.

July 11, 2020

1 hour ago, laurentppol said:

Does it say something?

Perhaps checking the output of "dmesg" that was recorded on both devices after a fresh reboot can gain more insight.

As you said you had copied everything in /boot, you also copied the kernel companion dtb files, did you?

July 11, 2020

On 5/23/2020 at 7:27 PM, laurentppol said:

Now I have copied everything (only different UUIDS) from working /boot directory to the one with problems.

(kernel, initrd, etc).

Just a shot into the dark. When you copied the kernel binary, you also copied its companion modules from /usr/lib/modules/<kernel-version> to your rootfs? Perhaps the initrd lacks an essential module that is later loaded from rootfs. You must use the same <kernel-version>directory label in your rootfs.

July 11, 2020

3 hours ago, laurentppol said:

What could I check / change next?

Verify the full verbose boot log of both devices.
Best obtained by serial console as it will most probably also preserve the uboot messages.

July 7, 2020

2 hours ago, hji said:

Is there any way to get hardware acceleration

You have proper hardware acceleration from the kernel already.

Quote

[   10.439569] etnaviv etnaviv: bound 130000.gpu (ops gpu_ops [etnaviv])
[   10.443294] etnaviv etnaviv: bound 134000.gpu (ops gpu_ops [etnaviv])
[   10.451085] etnaviv etnaviv: bound 2204000.gpu (ops gpu_ops [etnaviv])
[   10.451107] etnaviv-gpu 130000.gpu: model: GC2000, revision: 5108
[   10.451469] etnaviv-gpu 134000.gpu: model: GC320, revision: 5007
[   10.451559] etnaviv-gpu 2204000.gpu: model: GC355, revision: 1215
[   10.451571] etnaviv-gpu 2204000.gpu: Ignoring GPU with VG and FE2.0
[   10.452674] [drm] Initialized etnaviv 1.3.0 20151214 for etnaviv on minor 0

What you are probably missing is the xorg driver to make use of it.

July 6, 2020

54 minutes ago, Jop said:

I think, this should be handled by the pwm_ir_tx/gpio_ir_tx modules

For these modules to work, at least the correct Devicetree configuration must be available.

This way they know how to operate the tx led and how it is wired up.

July 5, 2020

1 hour ago, ravelo said:

what woulkd you recommend us to do

If I picked it out correctly, the USB IP of your h5 SOC will be driven by the musb driver.
So check if your kernel config has all components for OTG support enabled and the DT is configured for peripheral mode.
This is usually not the case with a default configuration because host mode is used more frequently.

July 5, 2020

17 hours ago, ravelo said:

[ 5.496280] udc-core: couldn't find an available UDC - added [g_ether] to list of pending drivers

USB Gadget is a device-independent kernel subsystem. For its operation it needs device specific UDC (USB Device Controller) support.

E.g.: usb-stack.png.9966d25928b55be5e55ddd0335e8e0b3.png
You at least missing proper hardware (DT) configuration and may be missing kernel UDC support.

July 5, 2020

14 hours ago, gounthar said:

use it to make an Orange Pi Zero or One seen as a video sink by the host computer.

An USB video sink is a standard USB host port consuming the video via UVC function. I.e. you plug in a USB webcam in your USB port and you get a /dev/videoX device.

14 hours ago, gounthar said:

My goal would be to grab the host's webcam content, encode and stream it on the SBC

This will not work quite well due to the bandwidth requirement for the raw video. Using native Ethernet would already be a challenge.
The proper way is to use hardware encoders at the host and forward the processed stream. With zero copy (dma_buf) video pipeline this puts little strain on the CPU.

June 30, 2020

3 hours ago, percu said:

So one more question: how I can change this name?

As you have chosen the legacy g_midi configuration interface, you have to do configuration while module-load.

"modinfo g_midi" will tell all available configurable parameters.

Sign In

Forums

Store

Crowdfunding

Applications

Events

Raffles

Community Map

Posts posted by usual user

Important Information