Closed nascs closed 4 months ago
如果你要在这里修改那跟客户回复一下
按照那个客户的代码做了一个测试,打开一个 spi 后设置 cs 脚为输出再上拉,是可以的
Tested by cross-compiling commit 0f1a43
with pull up / down changes, still receiving Not Implemented
error when running status = mraa_gpio_mode(dc, MRAA_GPIO_PULLUP);
. Can confirm that changes were correctly applied (as below lines are visible in /usr/include/linux/gpio.h
on target.
#define GPIOHANDLE_REQUEST_BIAS_PULL_UP (1UL << 5)
#define GPIOHANDLE_REQUEST_BIAS_PULL_DOWN (1UL << 6)
Still getting the Not Implemented
error on status = mraa_gpio_mode(dc, MRAA_GPIO_PULLUP);
, doing a full rebuild to see if this is on my side, though installation looks correct and libraries (libmraa.so
) have been updated.
I'm not getting a Not Implemented error, but I'm not currently passing the test, so I'm not sure my test method is working.
Did you test the code with branch Radxa_ROCK_PI_E ?
Yes, directly used latest commit df94ff9
with mraa makefile to cross-compile for aarch64 (Rock 3A). All files look correct in place, full rebuild eta 40 min.
Maybe issue with my setup -- should all files under mraa/include/
be included in root filesystem in /usr/include/
?
Adding these files to the target (using makefile install commands, see below) changes error to MRAA: Invalid resource.
See additions to buildroot mraa.mk:
define MRAA_INSTALL_TARGET_CMDS
# Create necessary directories
$(INSTALL) -d -m 0755 $(TARGET_DIR)/usr/include/{linux,arm,gpio}
# Install specific header file
$(INSTALL) -D -m 0644 $(@D)/include/linux/gpio.h $(TARGET_DIR)/usr/include/linux/gpio.h
# Install header files from include to /usr/include
for header in mraa_adv_func.h mraa_internal.h mraa_internal_types.h mraa_lang_func.h; do \
$(INSTALL) -D -m 0644 $(@D)/include/$$header $(TARGET_DIR)/usr/include/$$header; \
done
# Populate /usr/include/arm and /usr/include/gpio
for dir in arm gpio; do \
for file in $(@D)/include/$$dir/*; do \
if [ -f $$file ]; then \
$(INSTALL) -m 0644 $$file $(TARGET_DIR)/usr/include/$$dir/; \
fi; \
done; \
done
endef
From /tmp/messages
syslog:
Aug 4 09:00:51 smc local1.notice libmraa[241]: libmraa version 2022.08.1 initialised by user 'root' with EUID 0
Aug 4 09:00:51 smc local1.notice libmraa[241]: gpio: support for chardev interface is activated
Aug 4 09:00:51 smc local1.notice libmraa[241]: libmraa initialised for platform 'Radxa ROCK3 Model A' of type 35
Aug 4 09:00:51 smc local1.err libmraa[241]: [GPIOD_INTERFACE]: ioctl() error Invalid argument
Aug 4 09:00:51 smc local1.err libmraa[241]: gpiod: ioctl() fail
Aug 4 09:00:51 smc local1.err libmraa[241]: [GPIOD_INTERFACE]: error getting line handle
Where is the actual implementation of pull / up down behaviour to communicate to gpio controller (gpio-rockchip.c
?)? I can see ioctl() error in gpio_chardev.c in status = ioctl(fd, gpio_request, data);
.
I am using kernel 4.19 (see https://github.com/radxa/kernel/blob/stable-4.19-rock3/drivers/gpio/gpiolib.c) -- the valid flags don't include those that were added to the headers in your commit, as you can see below:
#define GPIOHANDLE_REQUEST_VALID_FLAGS \
(GPIOHANDLE_REQUEST_INPUT | \
GPIOHANDLE_REQUEST_OUTPUT | \
GPIOHANDLE_REQUEST_ACTIVE_LOW | \
GPIOHANDLE_REQUEST_OPEN_DRAIN | \
GPIOHANDLE_REQUEST_OPEN_SOURCE)
What kernel version are you using?
We are using 5.10 rkr4.1 branch for 3A.
@nascs need to add a compile switch to turn on pullup support optionally, as not all kernel supports this feature.
I am using kernel 4.19 (see https://github.com/radxa/kernel/blob/stable-4.19-rock3/drivers/gpio/gpiolib.c) -- the valid flags don't include those that were added to the headers in your commit, as you can see below:
#define GPIOHANDLE_REQUEST_VALID_FLAGS \ (GPIOHANDLE_REQUEST_INPUT | \ GPIOHANDLE_REQUEST_OUTPUT | \ GPIOHANDLE_REQUEST_ACTIVE_LOW | \ GPIOHANDLE_REQUEST_OPEN_DRAIN | \ GPIOHANDLE_REQUEST_OPEN_SOURCE)
What kernel version are you using?
I'm using Linux 5.10, and the GPIO interface currently used by mraa is gpiod.
Ok will either add support for pull-ups to 4.19 or upgrade to kernel 5.10, and test with mraa again, thanks. Is this correct gpiolib.c in 5.10 rkr4.1 for 3A -- https://github.com/radxa/kernel/blob/linux-5.10-gen-rkr4.1/drivers/gpio/gpiolib.c?
We are using that branch but I'd suggest you just upgrade the kernel as a whole. Picking code like that can cause a lot of issues.
Which uboot version are you using for 5.10 on Rock 3A? Only 5.10 seems to be for Rock5 -- https://github.com/radxa/u-boot.git. I am currently using stable-4.19-rock3 branch of radxa/u-boot
Built and working with 5.10, getting unknown platform error, have not changed ~make~ from previous version. In any case thanks for your help, will continue troubleshooting.
Please use our latest released image: https://github.com/radxa-build/rock-3a/releases/download/b25/rock-3a_debian_bullseye_xfce_b25.img.xz
I am building a custom Rock 3A image in Buildroot, cannot use the Debian image for my purposes.
We are currently using this branch for all non RK3588 products: https://github.com/radxa/u-boot/tree/rk3568-2023.10
Ok building with this. Would it be possible to provide .config
for U-Boot (2023.10) for Rock 3A? Previously used U-Boot 2017.09 with kernel 4.19, so many settings have changed.
I am currently using the rock-3a-rk3568_defconfig here https://github.com/radxa/u-boot/blob/rk3568-2023.10/configs/rock-3a-rk3568_defconfig but this is causing issues when configuring with Kconfig in Buildroot -> some parameters are overriden in U-Boot 2023.10 according to the logs.
.config:109:warning: override: reassigning to symbol ROCKCHIP_SFC
.config:111:warning: override: reassigning to symbol SPI_FLASH_MACRONIX
.config:112:warning: override: reassigning to symbol SPI_FLASH_XTX
.config:113:warning: override: reassigning to symbol SF_DEFAULT_SPEED
.config:114:warning: override: reassigning to symbol SF_DEFAULT_MODE
.config:116:warning: override: reassigning to symbol SCSI_AHCI
.config:117:warning: override: reassigning to symbol AHCI_PCI
.config:119:warning: override: reassigning to symbol SCSI
.config:120:warning: override: reassigning to symbol DM_SCSI
.config:124:warning: override: reassigning to symbol USB_DWC3_GENERIC
rock-3a-rk3568_defconfig
is the correct file. The warning is normal, since the original file could be maintained be 3rd party with various level of feature support, when we want to enable certain features across SoC, some configs could already be enabled in the file.
We do have some additional configs that are enabled for all our products. Since maintaining and editing 20+ files whenever we need to change global settings is a pain, they are stored separately and are applied by our build script at build time.
Thank this was very helpful, configuration is now correct - tested against radxa bsp tools. :)
Can you confirm which ddr binary (from rkbin/bin/rk35/rk3568-ddr-*
) should be used for this version (if any)?
Here is my related error in Buildroot (as we are using binman):
Image 'simple-bin' is missing external blobs and is non-functional: rockchip-tpl
/binman/simple-bin/mkimage/rockchip-tpl (rockchip-tpl):
An external TPL is required to initialize DRAM. Get the external TPL
binary and build with ROCKCHIP_TPL=/path/to/ddr.bin. One possible source
for the external TPL binary is https://github.com/rockchip-linux/rkbin.
Image 'simple-bin' is missing optional external blobs but is still functional: tee-os
/binman/simple-bin/fit/images/@tee-SEQ/tee-os (tee-os):
See the documentation for your board. You may need to build Open Portable
Trusted Execution Environment (OP-TEE) and build with TEE=/path/to/tee.bin
Image 'simple-bin-spi' is missing external blobs and is non-functional: rockchip-tpl
/binman/simple-bin-spi/mkimage/rockchip-tpl (rockchip-tpl):
An external TPL is required to initialize DRAM. Get the external TPL
binary and build with ROCKCHIP_TPL=/path/to/ddr.bin. One possible source
for the external TPL binary is https://github.com/rockchip-linux/rkbin.
Some images are invalid
rkbin is pulled in this command. BL2 (ddr bin) and BL31 are filtered with the following file name pattern and the latest one is determined by string sorting.
Thank you, successfully built kernel 5.10 and bootloader 23.10. Still receiving the Unknown platform
when running mraa-gpio
, will look more into it tomorrow.
mraa determines the platform by device tree's model field:
https://github.com/eclipse/mraa/blob/master/include/arm/radxa_rock_3a.h#L23
Did you change this value?
Have not changed the mraa header. The compatible file under /proc/device-tree/compatible
reads radxa,rock-3arockchip,rk3568
, and /model
reads Radxa ROCK3 Model A
. Perhaps this is a cross-compilation issue, though it worked on 4.19 which is strange.
Update -- Changes to makefile solved Unknown platform
issue. Pull-up/down resistors with mraa work! Issue now with initialising SPI. See full /var/log/messages
-- https://github.com/haelyons/mraa-spi-oled/blob/master/messages
Jan 1 12:03:26 smc local1.err libmraa[324]: spi: Failed opening SPI Device. bus:/dev/spidev3.0. Error 2 No such file or directory
How do you recommend enabling functions such as SPI and the UART serial pins? I previously used overlays=rk3568-fiq-debugger-uart2m0
in vars.txt
. Can I load for example the rk3568-fiq-debugger-uart2m0.dtbo
? I have tried compiling this dtbo
with the Radxa bsp
tool, and loading it with vars.txt (same as uEnv.txt) but this has not worked -- was previously correct for U-Boot 17.3 w/ kernel 5.10.
Your issue is likely due to SPI overlay not loaded, so you can check the our available overlays here: https://github.com/radxa/overlays/tree/main/arch/arm64/boot/dts/rockchip/overlays
All our overlays contain a compatible field for you to check whether they could be used with 3A.
FIQ Debugger is not the same as UART. You should use rk3568-uart2-m0
in your example.
The issue was that I was using .dts
as opposed to .dtbo
overlays, and my serial cable was broken, so nothing on this side. All GPIOs working, overlays loaded correctly, and can assign pull-ups. Thank you for the help :)
新产品开个新分支去处理
gpio pull up/down 的修改,我也在这个分支该吧,然后一起提交上去