Yeah, that’s about how we can debug from user-space… DO you have anything to plug into J1, usb-serial, so we can see what u-boot is doing…
Regards,
There serial port doesn’t get enabled until uEnv.txt is loaded from FAT partition, so I may be missing some stuff.
Failed to mount ext2 filesystem…
** Unrecognized filesystem type **
switch to partitions #0, OK
mmc0 is current device
Checking for /boot/uEnv.txt on mmc0:2
switch to partitions #0, OK
mmc0 is current device
Scanning mmc 0:1…
gpio: pin 56 (gpio 56) value is 0
gpio: pin 55 (gpio 55) value is 0
gpio: pin 54 (gpio 54) value is 0
gpio: pin 53 (gpio 53) value is 1
switch to partitions #0, OK
mmc0 is current device
gpio: pin 54 (gpio 54) value is 1
Checking for: /uEnv.txt …
reading uEnv.txt
387 bytes read in 3 ms (126 KiB/s)
gpio: pin 55 (gpio 55) value is 1
Loaded environment from uEnv.txt
Importing environment from mmc …
Checking if uenvcmd is set …
gpio: pin 56 (gpio 56) value is 1
Running uenvcmd …
Failed to mount ext2 filesystem…
** Unrecognized filesystem type **
Checking if client_ip is set …
Checking for: /boot.scr …
Checking for: /boot/boot.scr …
Checking for: /boot/uEnv.txt …
gpio: pin 55 (gpio 55) value is 1
215 bytes read in 24 ms (7.8 KiB/s)
Loaded environment from /boot/uEnv.txt
debug: [dtb=am335x-bonegreen.dtb] …
Using: dtb=am335x-bonegreen.dtb …
Checking if uname_r is set in /boot/uEnv.txt…
gpio: pin 56 (gpio 56) value is 1
Running uname_boot …
loading /boot/vmlinuz-5.10.186-bone-rt-r76 …
9880064 bytes read in 567 ms (16.6 MiB/s)
loading /boot/dtbs/5.10.186-bone-rt-r76/am335x-bonegreen.dtb …
90145 bytes read in 61 ms (1.4 MiB/s)
debug: [console=tty0 console=ttyS1,115200n8 console=ttyS1,115200n8 lcd_detect=0xfff7ff ipaddr= serverip= gatewayip= netmask=255.255.255.0 root=/dev/mmcblk0p2 ro rootfstype=ext4 rootwait fsck.mode=force fsck.repair=yes uio_pruss.extram_pool_sz=0x200000 net.ifnames=0] …
debug: [bootz 0x82000000 - 0x88000000] …
Kernel image @ 0x82000000 [ 0x000000 - 0x96c200 ]Flattened Device Tree blob at 88000000
Booting using the fdt blob at 0x88000000
Loading Device Tree to 8ffe6000, end 8ffff020 … OKStarting kernel …
Normally it would try to load the overlay after 90145 bytes read in 61 ms (1.4 MiB/s) so either /boot/uEnv.txt doesn’t have the correct details to load the overlay, or you’ve patched too much of our u-boot changes out…
Regards,
Maybe my bootloader is too old. I searched the u-boot source code for these keywords:
enable_uboot_overlays
uboot_overlay_pru
enable_uboot_cape_universal
and didn’t get any hits. I don’t know what u-boot is supposed to do when it sees these values set.
I’ll try this suggestion:
fdtoverlay -i am335x-bonegreen.dtb -o am335x-bonegreen.dtb AM335X-PRU-UIO-00A0.dtbo
If that doesn’t work, I’ll try using the latest u-boot. If that doesn’t work, I’ll try using the ‘minfs’ file system. At that point I’ll have everything from the “Getting Started” tutorial. If still doesn’t work, you may have an easier time supporting me. If it does work, maybe I’ll be able to hone in on what the difference is.
The fdtoverlay trick worked! So I tried creating a custom dts by copying the pruss section of the overlay into the am335x-bonegreen.dts and adding status = “okay”, and that also works.
/dts-v1/;
#include “am33xx.dtsi”
#include “am335x-bone-common.dtsi”
#include “am335x-bonegreen-common.dtsi”&pruss {
compatible = “ti,pruss-v2”;
ti,pintc-offset = <0x20000>;
interrupt-parent = <&intc>;
status = “okay”;
interrupts = <20 21 22 23 24 25 26 27>;
};/ {
model = “TI AM335x BeagleBone Green”;
compatible = “ti,am335x-bone-green”, “ti,am335x-bone-black”, “ti,am335x-bone”, “ti,am33xx”;chosen {
base_dtb = “am335x-bonegreen.dts”;
base_dtb_timestamp = TIMESTAMP;
};
};
So I added that to my custom device tree and now it works. The missing piece was in am33xx.dtsi in 4.4 kernel, but isn’t in am33xx.dtsi in the 5.10 kernel. I missed that.
Thanks for you help! I still may need more help figuring out how to fix or find replacement for gpio-of-helper.
I looked into the gpio-of-helper issue. I couldn’t track down where to add -DDEBUG to see the debug messages, so I added some printks where errors were being returned related to &gpio0. I was surprised to find it wasn’t only returning errors for gpio-of-helper, but anywhere in device tree that has &gpio0.
[ 2.946724] of_get_named_gpiod_flags: cd-gpios ERR_PTR(-EPROBE_DEFER)
[ 3.661613] of_get_named_gpiod_flags: gpio ERR_PTR(-EPROBE_DEFER)
[ 3.672634] of_get_named_gpiod_flags: gpios ERR_PTR(-EPROBE_DEFER)
An error is also returned for one of my LEDs in the “gpio-leds” section and for the CD signal in the mmc1 section, but these appear to be functioning correctly.
I also noticed that even though gpio-of-helper only complains about &gpio0, it fails to export the correct gpio#'s in /sys/class/gpio for the other gpios.
I’m going to stop looking into this and start looking for an alternative.
Another question: I need a timer with uS resolution. To accomplish this, I wrote a kernel module that sets up timer4 with 1MHz output and wired it to TCLKIN pin. Then I setup timer6 to use TCLKIN, which gives me a free running timer with uS resolution that wraps at 0xFFFFFFFF.
This kernel module won’t build with the latest kernel due to missing header files and I would like to find another way to do this.
Can I do this with device tree?
I think I have timer4 setup with omap-dmtimer-pwm to give me 1MHz output. I can’t verify because the trace connecting the output to TCLKIN is under the part. I don’t know how to enable and configure timer6 to use TCLKIN in device tree.
Any ideas?
There is a ti,clock-source option: https://github.com/beagleboard/bb.org-overlays/blob/master/src/arm/BB-PWM-TIMER-P8.07.dts#L63-L64
Regards,
Sorry for bouncing back and forth between topics, but I spent some time trying to figure out why the gpio-of-helper isn’t working. A significant clue to the problem is that the gpios end up with the wrong name when gpio-of-helper exports them. For example, this
gpio {
compatible = “gpio-of-helper”;
status = “okay”;
pinctrl-names = “default”;
pinctrl-0 = <&gpio_pins>;
bla {
gpio-name = “bla”;
gpio = <&gpio3 17 0>;
input;
};
};
will give you a /sys/class/gpio/gpio49 directory instead of /sys/class/gpio/gpio81. If you cat /sys/class/gpio/gpio49/value, it will give you the value on pin gpio3_17. The gpio#'s are off by 32 (one port). This tells me that this can probably be fixed with one line of code, but getting familiar enough with the code to find that line has proven difficult. It basically reads <&gpio3 17 0> from the device tree and iterates over a link list of gpio_devices and gets a match one port too early. I don’t know if it’s not reading the device tree correctly, or the link list is not created correctly.
Are you familiar with this area of the code? If so, does this clue tell you where the problem may be?
I spent two weekends trying to figure out what’s wrong with the gpio-of-helper driver and got nowhere. Now I’m trying to export the gpio in bash script and it doesn’t work either. Here’s what I’m doing in device tree:
&am33xx_pinmux {
gpio_pins: pinmux_gpio_pins { // The GPIO pins
pinctrl-single,pins = <
AM33XX_IOPAD(0x898, PIN_INPUT_PULLUP | MUX_MODE7)
>;
};
};
gpio {
compatible = “gpio-of-helper”;
status = “okay”;
pinctrl-names = “default”;
pinctrl-0 = <&gpio_pins>;
};
It looks like the pin is setup correctly:
devmem 0x44e10898
0x00000037
Here’s what I’m doing in bash script:
echo “68” > /sys/class/gpio/export
echo “in” >/sys/class/gpio/gpio68/direction
I always read 0 whether the pin is high or low:
cat /sys/class/gpio/gpio68/value
0
Any idea why this method of using gpio isn’t working for me either?
I forgot to mention that I can see the pin change value using devmem but not by reading value file
//jumper pin to ground
devmem 0x481ac138
0x00000000
cat /sys/class/gpio/gpio68/value
0
//remove jumper and allow pullup to pull high
devmem 0x481ac138
0x00000010
cat /sys/class/gpio/gpio68/value
0