How read AArch64 register in AArch32 mode - raspberry-pi

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.

Related

Azure NetX Duo only provides the driver for LAN8742 compatible Ethernet PHYs. How can I manage other Ethernet PHYs?

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.

How to load vfio driver before ahci driver with mkinitcpio?

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.

Application not loading after DFU:Leave

I am trying to program the STM32F401 flash on our board in DFU mode. I am using the dfu-util tool in my linux computer.For my project requirements the BOOT 0 pin is always kept high throughout the process.
I am using the following command to flash and jump to application code.
dfu-util -a 0 -s 0x08000000:leave -D <location-to-binary>.bin
After the flashing is done I can see through 'lsusb' command that sometimes the MCU is not out of DFU boot loader, and sometimes out of it. Either way the application does not start.
When I further try to use the leave command when it's in bootloader, it shows the following log and the above situation continues,
Copyright 2005-2009 Weston Schmidt, Harald Welte and OpenMoko Inc.
Copyright 2010-2021 Tormod Volden and Stefan Schmidt
This program is Free Software and has ABSOLUTELY NO WARRANTY
Please report bugs to http://sourceforge.net/p/dfu-util/tickets/
Opening DFU capable USB device...
Device ID 0483:df11
Device DFU version 011a
Claiming USB DFU Interface...
Setting Alternate Interface #0 ...
Determining device status...
DFU state(10) = dfuERROR, status(10) = Device's firmware is corrupt. It cannot return to run-time (non-DFU) operations
Clearing status
Determining device status...
DFU state(2) = dfuIDLE, status(0) = No error condition is present
DFU mode device DFU version 011a
Device returned transfer size 2048
DfuSe interface name: "Internal Flash "
DfuSe command mode
Submitting leave request...
Transitioning to dfuMANIFEST state
Thanks in advance for any advice or help.
I found the issue. I had to uncomment the define USER_VECT_TAB_ADDRESS in the system_stm32f4xx.c file.
Basically what was happening was that bootloader was looking for a loadable vector address from the flash application. With the USER_VECT_TAB_ADDRESS commented the pointer to the vector address kept pointing to the bootloader vector table effectively crashing the flash application resetting the controller. With the BOOT 0 pin high it kept loading into bootloader with each reset.
More information about this is available in this similar question:
STM32G474 bootloader exit

Regulator configuration for RTC backup battery in i.MX6 PMIC

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.

iMX6: MSI-X not working in Linux PCIe device driver

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?