Thanks Robert, I have all the errors cleaned up by copying the regulatory.db, regulatory.db.p7s, am335x-bone-scale-data.bin and am335x-pm-firmware.elf to /lib/firmware.
Still have the strange issue with the serial terminal locking up. Basically canāt use it. Only for read only.
// add function here to set pin mux registers before user space programs
#ifdef CONFIG_SOC_AM33XX
bgpioSetPinMux();
#endif
/* Do the rest non-__init'ed, we're now alive */
rest_init();
and the output during boot
[ 0.003721] bgpioWriteMem Set address:0x44e10834 value:0x37
[ 0.003746] bgpioWriteMem Set address:0x44e10830 value:0x37
[ 0.003753] bgpioWriteMem Set address:0x44e1083c value:0x37
[ 0.003760] bgpioWriteMem Set address:0x44e1088c value:0x37
If anyone knows of a way to set the pin mux via device tree overlays and then free the pins for user space libgpiod please let me know. I would rather not be compiling the kernel just to get some pins to pull up.
Yes, as I have been pointing out to you earlier,
I really does feel like youāre crossing 3 bridges and 2 pubs to get water from a creak beyond.
I think your time would be better spent if you figured out why the pinctrl driver
fails to set that bit 4 instead. That way everybody wins.
Youāve probably posted it before, but to be honest, Iāve lost track of your threads,
so if itās not too much to ask, could you please post the overlay you have right now
and Iāll take that and apply it myself to see if I can reproduce.
/dts-v1/;
/plugin/;
#include <dt-bindings/gpio/gpio.h>
#include <dt-bindings/pinctrl/am33xx.h>
/*
* Record overlay in /sys/firmware/devicetree/base/chosen/overlays
*/
&{/chosen} {
overlays {
BB-P8_45-0x37-00A0.kernel = __TIMESTAMP__;
};
};
/*
* Free up the pin previously used by another cape
*/
&ocp {
P8_45_pinmux { status = "disabled"; };
};
/*
* Configure pinmux for P8_45 as GPIO
*/
&am33xx_pinmux {
bb_lplcP8_45_pins: pinmux_bb_lplcP8_45_pins {
pinctrl-single,pins = <
AM33XX_PADCONF(AM335X_PIN_LCD_DATA0, PIN_INPUT_PULLUP, MUX_MODE7)
>;
};
};
/*
* GPIO1_6 defined for userspace control
*/
&gpio1 {
lplc_pin: lplc_pin {
gpios = <&gpio1 6 GPIO_ACTIVE_HIGH>; /* Logical HIGH is voltage HIGH */
status = "okay"; /* Enable the GPIO controller line */
};
};
add BB-P8_45-0x37-00A0.dtso to other dtso files in linux-stable-rcn-ee/arch/arm/boot/dts/ti/omap
edit Makefile, insert BB-P8_45-0x37-00A0.dtbo in random spot inside makefile between other dtbo.
Oh, Iām sure that what you made works, Iām just saying, itās the wrong way to go about it.
Now, I havenāt checked this personally yet, but one thing that you seem to be missing
is a reference to that stuff you put into &am33xx_pinmux.
It doesnāt get applied āon itās ownā; it needs another node, one thatās active,
to reference it with a pinctrl-<n> = &bb_lplcP8_45_pins statement. (n normally 0).
Just as an example, I put the following into ChatGPT:
can you make a device-tree overlay for me that turns the input on p8.13 on a beaglebone black into an input with a pullup and creates a gpio-key node as well
Thatās because right now weāre just looking to see if we can get the kernel
to set the right value in the PINMUX register.
Thereās no need to complicate the matter by adding the libgpiod layer on
top when the device-tree is in question.
I got tired of compiling kernels so I decided to read the pinmux settings on boot from a file /etc/am335xpinmux.conf. The format of the file is pretty basic
cat /etc/am335xpinmux.conf
# am335x pin mux address and value to set
# this file is read by the am335xsetpinmux.c Linux kernel driver
# located in drivers/gpio
# address=value
0x44e10834=0x37
0x44e10830=0x37
0x44e1083c=0x37
0x44e1088c=0x37
0x44e108b0=0x37
0x44e108b4=0x37
0x44e108a8=0x37
0x44e108ac=0x37
0x44e108a0=0x37
0x44e108a4=0x37
The driver just reads the file and sets the control registers to the value, very simple. The kernel delays the file read by 10 seconds so that the file system is up and running. Seems to work. Here is the output during boot.
If anyone is interested in this kernel mod let me know. At this point, Iām happy with the static settings of the pinmux and Iām moving on to other things. This kernel business is time consuming. Iāll post the kernel driver for documentation when I get a few minutes.
Already available? Show me. Have you tried to used libgpiod to set pinmux from userspace? please show me the device tree overlay that sets the pins mux and then releases the pins for general user space libgpiod use. I would like to use that one.
Itās this āfeatureā thatās currently broken and most users use the old 5.10.x hacks.. iād love there to be a simple tool, kinda like what you did with GitHub - beagleboard/pinmux Ā· GitHub that we can share on am335x and k3 that allows user to bypass ālibgpiodā never ending not working..
In most cases gpio-led works great for āoutputāā¦ input with gpio-key kinda works, but old sys dev was eaasier for input.. if you want to change pinmux dev mem ā¦
I have to admit, Iām a little surprised that a 13 year old board still has Beta code for simple IO. I donāt really understand the history or why things changed, maybe there was a good reason. libgpiod is a beast and is difficult to use. Just compared to Raspberry PI WiringPI library.
hehe.. for 3.8 thru 5.10, we got away with abusing kernel structures.. donāt look too close in that code, youāll see us just āover-writingā things..
Then when we grew a few arm64 targets and riscv64 targetsā¦ (Which lead to the question, do you port the am335x pin things to other non arm335x)
Look closely at PIās WiringPI library they just use dev mem.. We were trying to work with the kernel libgpiod.. but after 6.0.x ā now theyāve been activly removing the gpio structures in the kernel we abused in 3.8 ā 5.10.
Soā¦ we chose wrong.. should have just gone the pi route and used dev mem from the start..
Except /dev/mem doesnāt work on am335x. You cannot write to the pinmux registers via /dev/mem on the BBBās. The am335x has hardware blocks that only allow writing to those locations from within the protected kernel. Iāve been trying to work around that for a long time and have not found a way. You HAVE to have some sort of kernel driver to do the actual write. I though about some sort of driver that created a simple /dev/bb-pin-mux character device that you would just write a pin and mux value to (like: āP9-46 gpioā or something, just never got around to doing it.
