If you can boot from the SD card, see if there is anything on the eMMC by examining the filesystem there (fdisk, mount, etc.). I don’t have a RED in front of me but I have some written notes. /dev/mmcblk2 should have 4 partitions (uBoot, /boot, /vendor, and /). /dev/mmcblk1 is the SD card.
We have 2 RED boards and the one I just examined shows 12/16/2020. I’ll check the other later but I am pretty it should be the same because they arrived at the same time. If not I will post a correction.
Yes, our company received 2 RED boards several months ago and they booted up with Debian “out of the box”. We sourced them from Arrow Electronics.
I assume you don’t even see the uBoot menu? If not, the problem is not the version of Linux loaded on the eMMC. For troubleshooting, I suggest downloading the SD card image, write it to the SD card, set the DIP switches appropriately, and boot from the SD card. This would check that the board can come up even if the eMMC has failed or is empty.
And one more minor thought. I found this change:
https://github.com/STMicroelectronics/linux/releases/tag/v4.19-stm32mp-r3.3
“usb: dwc2: disable Link Power Management on STM32MP1 HS OTG”.
This patch could fix the USB issues I am seeing.
To close this discussion I figured out, at least partially, what was going on.
While I don’t have a full understanding of the issues, VMware Workstation 16 Pro version 16.1.2 USB virtual hardware driver does NOT work with Windows 10 and a Ubuntu guest. During my tests, I always had VMware running all the time. USB redirection worked fine with the RED board but not the BRK board so that is why I never suspected VMware to be the problem. I speculate that there is a timing or power issue with USB redirection and device/host negotiation with the gadget driver that is interfering with the Windows USB subsystem.
The workaround is fairly simple: don’t run VMware Workstation. Or if you do simply remove the USB Controller from the virtual machine’s settings. There may be a setting in VMware that might work but I haven’t found it.
Thanks for everyone’s help, Carlos
Sorry if this is a duplicate post.
I am now looking for the BRK device tree source for 4.19. The DTS posted on GitHub appears to be Linux 5.4.
The RNDIS network driver works on an older laptop running Ubuntu 20.04 server and USB 2.0 and 3.0 ports. I have to manually assign the IP address, annoying, but workable for now.
Thank you, Carlos
PGA4 is used by the digital camera interface. I suggest using a different pin.
Also I solved my problem with loading the device driver by recompiling the kernel with the CONFIG_KEYBOARD_MATRIX=y option. The stock kernel from Octavo does not work with GPIO matrix keypads. Docs: https://www.kernelconfig.io/config_keyboard_matrix
I am a little confused as to matrix keypads. Is a “GPIO matrix keypad” the same as a regular “matrix keypad”? It was my understanding they are different types of hardware.
What I have is a GPIO driven keypad where the cols are outputs and rows are inputs.
Thx, Carlos
Neeraj,
Thanks, I will give this try.
This is the config from /proc/config.gz:
CONFIG_INPUT_MATRIXKMAP=y
No CONFIG_KEYPAD_MATRIX config setting. Do I need to rebuild the kernel or is there a boot parameter that will do the trick with the stock Octavo kernel?
Also, grep -i matrix /lib/modules/4.19.94/modules.builtin:
kernel/drivers/input/matrix-keymap.ko
Thank you, Carlos
+1, and including the STM32CubeIDE too. I’m brand new to the IDE and haven’t gotten the “Linux core” and /dev/ttyACM0 working yet.
See also: https://octavosystems.com/forums/topic/getting-started-with-osd32mp1-brk-st-link-jtag-interface/
Octavo Systems LLC all rights reserved
OCTAVO is registered in the U.S. Patent and Trademark Office. OSD, C-SiP, and the Octavo Logo are trademarks of Octavo Systems LLC.
"*" indicates required fields
"*" indicates required fields
"*" indicates required fields
"*" indicates required fields