I'm developing an application for STM32F4 with Azure RTOS Netx Duo. In particular I'm trying to adapt the example Nx_TCP_Echo_Server application for my board where is present the Ethernet Phy ADIN1200 produced by Analog Devices.
Note about example Nx_TCP_Echo_Server
The Nx_TCP_Echo_Server example application has been made for a STM32F429ZI-NUCLEO demo board (code of Nx_TCP_Echo_Server on github).
In the demo board STM32F429ZI-NUCLEO the Ethernet Phy is compatible with the lan8742 driver (see the lan8742 driver code on GitHub). Unfortunately the Ethernet PHY ADIN1200 present on my board is not compatible with that driver.
I have noted that the sixth parameter of the function nx_ip_create() is the pointer function nx_stm32_eth_driver.
This pointer function points to lan8742 driver.
Below I show the invocation of the function nx_ip_create() present in the file app_netxduo.c (code of app_netxduo.c) of the Nx_TCP_Echo_Server example application:
/* Create the main NX_IP instance */
ret = nx_ip_create(&IpInstance, "Main Ip instance", NULL_ADDRESS, NULL_ADDRESS, &AppPool, nx_stm32_eth_driver,
pointer, 2 * DEFAULT_MEMORY_SIZE, DEFAULT_PRIORITY);
The documentation of NetX Duo reports the following info:
The NX_IP structure contains everything to manage a single IP instance. This includes general TCP/IP protocol information as well as the application-specific physical network driver's entry routine. The driver's entry routine is defined during the nx_ip_create service. Additional devices may be added to the IP instance via the nx_ip_interface_attach service.
My development environment
My development environment is composed by:
STM32CubeMX version 6.7.0
In the STM32CubeMX I have installed the Package STM32F4 version 1.27.1
To use ThreadX I have added to CubeMX the software pack X-CUBE-AZRTOS-F4 version 1.1.0
By the previous environment I can find only the driver for LAN8742.
My question
How can I find other Ethernet PHY drivers for NetX Duo other than the one for lan8742?
EDIT
I have found this driver for ADIN1200 but it is very far from the driver lan8742.c provided by my development tool (see the code of lan8742).
In fact the API of the 2 drivers are very different; for example NetX Duo (and before it: LwIP) needs a function like LAN8742_RegisterBusIO() (present in the LAN8742 driver) to init a structure with pointer functions useful to write and read registers of the Ethernet PHY, but in this driver this function and its data structures are not present.
You can find different phy drivers from https://github.com/azure-rtos/samples.
mimxrt1060：KSZ8081RNB
same54：KSZ8091RNA
stm32f746：LAN8742A-CZ-TR
rx65n rsk：DP83620SQE
For others, you will need to develop the driver by yourself, based on existing ones.
Related
Good morning all,
I'd want to attach to vfio driver at boot my secondary sata controller in a manjaro os (kernel 5.16.7).
Usually, I add the devices in /etc/modprobe.d/vfio.conf, for example:
options vfio-pci ids=10de:100c,10de:0e1a,1b4b:9230,15b3:6274,1106:3403
In this example, there is gpu audio and video (10de), the sata controller (1b4b), an infiniband card (15b3) and firewire (1106).
Then, I add the modules in /etc/mkinitcpio.conf:
MODULES=(vfio_pci vfio vfio_iommu_type1 vfio_virqfd)
making sure that modconf is in the HOOKS:
HOOKS=(modconf base udev autodetect block filesystems keyboard)
Finally I generate initramfs:
mkinitcpio -P
All quite good, devices are attached to vfio, except for the sata controller, which is attached to the ahci driver (if not in use by some vm).
If I start the kvm vm with the sata controller set to be passed through, vfio driver attaches to it, but that's not what I'd want: the goal is to attach that sata controller to vfio at boot (not attaching it to vfio "on the fly").
I found some instructions for other oses, for example here:
https://gist.github.com/kiler129/4f765e8fdc41e1709f1f34f7f8f41706
The op explains that ahci driver loads before vfio, but manjaro uses mkinitcpio and my issue is that I don't understand how to adapt/translate those instructions for my os.
I'm switching with the phycore i.MX6 som from phytec's dev kit to an own board. The usermanuals for both the som and devkit can be found on phytec's page. Now I want to configure the rtc to keep the time during reboot's and poweroffs.
The battery (in my case supercap) is connected to the VDD_BAT pin of the phycore i.MX6 som (page 10). The internal PMIC is the da9062 connected via the i2c bus which is configured in the som dtsi file as rtc1.
imx6qdl-phytec-phycore-som.dtsi:
...
aliases {
rtc1 = &da9062_rtc;
};
...
&i2c3 {
pmic#58 {
da9062_rtc: rtc {
compatible = "dlg,da9062-rtc";
};
};
};
This file I didn't touch at all.
Next, I told the kernel to take his hwclock and systime time from rtc1 instead of rtc0:
CONFIG_RTC_HCTOSYS_DEVICE="rtc1"
CONFIG_RTC_SYSTOHC_DEVICE="rtc1"
The driver is being loaded correctly as far as I can tell:
dmesg | grep rtc
[ 2.489836] da9063-rtc da9062-rtc: rtc core: registered da9063-rtc as rtc1
[ 2.499713] snvs_rtc 20cc000.snvs:snvs-rtc-lp: rtc core: registered 20cc000.snvs:snvs-rtc-lp as rtc2
[ 3.260348] da9063-rtc da9062-rtc: setting system clock to 2000-01-01 02:37:55 UTC (946694275)
and
cat /sys/class/rtc/rtc1/name
da9063-rtc da9062-rtc
Now, I can set the time via date and transfer it to the hwclock via
hwclock --systohc
.
After rebooting the system and hwclock is set to the previously set date which is fine. After cutting the power the clock gets reset.
I've measured the voltage of the supercap which is around 220mV. The datasheet of the da9062 tells me the chip does have an regulator for the battery which needs to be configured (Table 127: BBAT_CONT (0x0C5)).
As far as I understand the kernel/rtc subsystem, the driver for the rtc should take care of the charging of the battery or provide an userspace interface so I can do it myself. But I can't find anything on this topic.
I am using yocto to build the kernel/image for my board.
Is there something I'm missing or do I need to patch the driver myself in order to charge the supercap? Maybe there's an option in the devicetree to set the charging voltage and current for the cap?
I appreciate any ideas and suggestions, thanks.
Aparently the driver does not support charging a battery/supercap out of the box and it has exclusive access rights to the i2c device address which prevents userspace applications to access the device.
My solution to this problem is to set those values before the driver takes over:
Since this i2c bus is already configured in my barebox devicetree, I can access it before I boot the kernel (provided barebox is compiled with the i2c subsystem enabled in menuconfig). Here I can run a script which sets the BBAT and PD registers to enable charging the supercap.
Though, the cleaner solution would be to extend the driver and provide a userspace interface for this functionality.
Another possible solution I did not investigate would be to check if the driver can be compiled as a module, so I could unload the module, set the registers and load it again.
i have a raspberry pi4 board that powered with Cortex-A72 processor. in this processor exist a special register that named "ID_AA64PFR0_EL1". document of Cortex-A72 explains:
To access the ID_AA64PFR0_EL1 in AArch64 state, read the register with:
MRS , ID_AA64PFR0_EL1; Read AArch64 Processor Feature Register 0
as document indicated with above command we could read ID_AA64PFR0_EL1 register in AArch64 mode. but official raspbian os only support AArch32 mode. so i want to know there is anyway that let me read ID_AA64PFR0_EL1 register in AArch32 mode?
Seems it's possible to get access to ID_AA64PFR0_EL1 in AArch32 mode.
According to "Architecture Reference Manual ARMv8"
ID_AA64PFR0_EL1, AArch64 Processor Feature Register 0 ...
Configurations
AArch64 System register ID_AA64PFR0_EL1 is architecturally mapped to
External register EDPFR
EDPFR, External Debug Processor Feature Register
EDPFR[31:0] can be accessed through the internal memory-mapped interface
According to same "Architecture Reference Manual ARMv8" and "ARM® Cortex®-A72 MPCore Processor, Technical Reference Manual"
To access the ID_AA64PFR0_EL1 in AArch64 state, read the register
with: MRS <Xt>, ID_AA64PFR0_EL1; Read AArch64 Processor Feature Register 0
The ID_AA64PFR0[31:0] can be accessed through the
memory-mapped interface and the external debug interface, offset
0xD20. The ID_AA64PFR0[63:32] can be accessed through the
memory-mapped interface and the external debug interface, offset
0xD24.
So you should check manufacturing documentation on your chip, and find out at what address "debug interface" is mapped.
After that read [addr + 0xd20] & [addr + 0xd24]
Enjoy.
I'm trying to get MSI-X working on an iMX6 (Freescale/NXP/Qualcomm) CPU in Linux v4.1 for a PCIe character device driver. Whenever I call either pci_enable_msix() or pci_enable_msix_range() or pci_enable_msix_exact() I get an EINVAL value returned. I do have the CONFIG_PCI_MSI option selected in the kernel configuration and I am also able to get single MSI working with pci_enable_msi(), but I cannot get multiple MSI working either.
I have tested my driver code on an Intel i7 running kernel v3 with the same PCIe hardware attached and I was able to get MSI-X working without any problems so I know my code is correctly written and the hardware is correctly functioning.
When running on the iMX6 I can use lspci -v to view that the hardware has MSI-X capabilities and see the number of IRQs it allows. I can even get the same correct number in my driver when calling pci_msix_vec_count().Questions
Are there any other kernel configuration flags I need to set?
Is there anything specific to the iMX6 CPU I need to consider?
Does anyone have any experience with the iMX6 and either MSI-X or
multiple MSI?
When you insert LKM with insmod it does not seem to execute defined probe() function. What do I need to do to trigger it?
Background: trying to create driver for MAX14830 for old kernel (2.6.39). Cannot use one available (max310x.c) because of old kernel, no support for regmap etc. In the source tree of old kernel there is max3107 driver (same thing, but for 1 serial port, while 14830 has 4). Both drivers use probe functions for initialization, as the SOC communicates with MAX chip over spi. I want to develop driver as LKM first.
What could be my problem?