support Beaglebone Black board use esp-hosted over SPI

[vuhailongkl97]

Hello,
I have ported this project to my BBB board.
I tested WiFi APIs with python and it worked, with Bluetooth some function still not work as my expectation, I'm working on it. Please consider to merge this for everyone who interested in this project for BBB.
Thanks

Note:
Currently throughput speed is not good ( Download/Upload < 3Mbps)

[MRobertEvers]

Hi, I was just browsing this PR to see how difficult it would be to port to another platform. It doesn't seem to bad.

This doesn't matter technically, because all the SPI0 pins are mode 0, but I think you have the comments for mosi and cs0 switched. I suppose this might matter if someone is looking at this in the future.

fragment@3 {
        // HERE -> THIS SHOULD BE // spi_D1 mosi
        // spi_cs0_
        target = <&P9_17_default_pin>;
        __overlay__ {
                pinctrl-single,pins = <0x158 0x10>;
            };
    };
    fragment@4 {
        // HERE -> THIS SHOULD BE // spi_cs0
	// spi_D0 mosi
        target = <&P9_18_default_pin>;
        __overlay__ {
                pinctrl-single,pins = <0x15c 0x10>;
            };
    };

Image is from the AM335x TRM.

Also, if I'm wrong, just disregard, I'm fairly new to embedded linux.

[vuhailongkl97]

Hi @MRobertEvers
I have just checked the offset of the 2 pins. Its incorrect, i'll fix this soon . Thanks.

[vuhailongkl97]

@MRobertEvers
I afraid that it is wrong when you said "This doesn't matter technically, because all the SPI0 pins are mode 0"
I thought that, however when I don't set spi mode for the SPI0 pins. SPI0 doesn't work
I figured out that in the official image from beagleboard.org, device tree for SPI0 pins didn't set mode for SPI0 as default.
below is an example for P9_18 SPI D1 MOSI

in exported device tree:

P9_18_pinmux {
			pinctrl-5 = <0x1ae>;
			compatible = "bone-pinmux-helper";
			pinctrl-3 = <0x1ac>;
			pinctrl-1 = <0x1aa>;
			pinctrl-8 = <0x1b1>;
			pinctrl-6 = <0x1af>;
			status = "okay";
			pinctrl-4 = <0x1ad>;
			pinctrl-2 = <0x1ab>;
			pinctrl-0 = <0x1a9>;
			pinctrl-7 = <0x1b0>;
			pinctrl-names = "default", "gpio", "gpio_pu", "gpio_pd", "gpio_input", "spi", "i2c", "pwm", "pru_uart";
		};

default gpio mode for P9_18 is ptrctrl-0 0x1a9

					pinmux_P9_18_default_pin {
						pinctrl-single,pins = <0x158 0x37>;
						phandle = <0x1a9>;
					};

however I expect it is 0x10 instead of 0x37
0x158 0x10 /* spi0_d1, OUTPUT_PULLUP | MODE0 */

[mantriyogesh]

I am not too sure, if SPI mode of 0 is being discussed.
I assume you are using 'ESP32' chipset with reference from #129.

This is ESP32 specific link and doesn't apply to other chipsets like ESP32-C3:
https://docs.espressif.com/projects/esp-idf/en/latest/esp32/api-reference/peripherals/spi_slave.html#restrictions-and-known-issues
It is overall better to use mode 1 or mode 3 then 0 or 2 considering timing considerations.

[mantriyogesh]

@vuhailongkl97 and @MRobertEvers

Thank you for the PR and all your efoorts & inputs.

We will review this PR and let you know further comments or once it is merged to master.

As I understand, the throughput is much less that what we expect.
Some comments:

1. I hope the (all debug) logs are removed before taking the throughput figures.
2. Can you please shorten the length of jumper wires and try?
3. Can you please retry other modes like SPI1 and SPI3?
4. Is it possible to get the logic analyzer graphs, to understand what is wrong?
   We face lower SPI frequency even when we set 10MHz in case of Raspberry Pi. The problem in case of Raspberry Pi is RaspberryPi_SPI_Clock_lower_than_expected as listed in ESP-Hosted SPI documentation. Overall Logic analyzer dump would help to understand any wrong doing.

[vuhailongkl97]

@mantriyogesh . Thanks for the comments.
I used ESP32 wroom and SPI mode 2 for the testing. I'll try some points in your comments and let you know when I have a result. However I'm only able to test on software only (I don't have any environment to get logic analyzer graphs)

[vuhailongkl97]

@mantriyogesh
I made SPI wire connection to be shorter and change SPI from mode 2 -> mode 1, Both esp & host didn't enable debug log too much ( some notifying, informing that connection is establish for example) and make ESP near Wifi station. I got a increase throughput performance.

debian@beaglebone:~/host_esp/python_support$ speedtest-cli 
Retrieving speedtest.net configuration...
Testing from Viettel Group (27.67.133.159)...
Retrieving speedtest.net server list...
Selecting best server based on ping...
Hosted by FPT Telecom (Hanoi) [0.41 km]: 75.909 ms
Testing download speed................................................................................
Download: 4.92 Mbit/s
Testing upload speed......................................................................................................
Upload: 5.26 Mbit/s

[MRobertEvers]

Using ESP32-C3-DevKitC-02v1.1 and BeagleBoard Black

Using long (20cm! wires) and SPI mode 2.

Compiled from source using -0g.

debian@beaglebone:~/bbb-hosted/host/linux/host_control/python_support$ speedtest-cli
Retrieving speedtest.net configuration...
Testing from ()...
Retrieving speedtest.net server list...
Selecting best server based on ping...
Hosted by () [399.81 km]: 1688.95 ms
Testing download speed................................................................................
Download: 6.45 Mbit/s
Testing upload speed......................................................................................................
Upload: 8.70 Mbit/s

The measurements were pretty inconsistent, but that is a pretty good rate for the setup. Very nice.

[vuhailongkl97]

@MRobertEvers great.
Hope this PR will be approved & merged soon :).

[CLAassistant]

Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.
_{You have signed the CLA already but the status is still pending? Let us recheck it.}

[HumbertoOntiveros]

Hello guys,
Currently I'm working on my own custom Embedded Linux using a BBB board, i´m trying to add WIFI to my project and I'm using this pull request as a guide, i'm using "linux-4.19.285" version kernel and u-boot as boot loader, the kernel configuration that i'm using is "multi_v7_defconfig" and the device tree is "am335x-boneblack.dtb", i've successfully compiled the esphosted module out of tree but for some reason, when i'm tring to apply the overlays to the main dtb at the uboot command line i get this error message:

=> fatload mmc 0:1 0x89000000 BBB_spidev_disabler.dtbo
946 bytes read in 2 ms (461.9 KiB/s)
=> fdt addr 0x88000000
Working FDT set to 88000000
=> fdt apply 0x89000000
failed on fdt_overlay_apply(): FDT_ERR_NOTFOUND
base fdt does did not have a /symbols node
make sure you've compiled with -@
=>

also at the time of compiling the "BBB_spidev_disabler.dts" i get this warning message:

dtc -O dtb -o BBB_spidev_disabler.dtbo -b 0 -@ BBB_spidev_disabler.dts
BBB_spidev_disabler.dts:42.27-44.19: Warning (unit_address_vs_reg): /fragment@5/overlay/channel@0: node has a unit name, but no reg or ranges property
BBB_spidev_disabler.dts:45.27-47.19: Warning (unit_address_vs_reg): /fragment@5/overlay/channel@1: node has a unit name, but no reg or ranges property

any idea about how to fix this problem?
thanks in advance.

[vuhailongkl97]

@HumbertoOntiveros as I remember , you don't need to load by yourself. just follow the readme.md docs/Linux_based_host/SPI_setup_for_BBB.md . it will move the bbb.dtbo to /lib/firmware and uboot load it for you.

[HumbertoOntiveros]

@HumbertoOntiveros as I remember , you don't need to load by yourself. just follow the readme.md docs/Linux_based_host/SPI_setup_for_BBB.md . it will move the bbb.dtbo to /lib/firmware and uboot load it for you.

yeah, you're right @vuhailongkl97 but as i mentioned before i'm working in my own custom linux from scratch, i'm not using the one broadcasted by the provider, for that reason i'm doing it in this way.