I am running dpdk on x86 and I running one application fips_valudation. I just want to know how to give. .req file for that application
According to the dpdk fips_validation docs:
./fips_validation [EAL options] -- --req-file FILE_PATH/FOLDER_PATH
For more info refer here: https://doc.dpdk.org/guides/sample_app_ug/fips_validation.html
Related
I have installed DPDK-19.11.1 LTS successfully as follows：
And the NIC I have bound as follows:
If I run an example (dpdk/dpdk-stable-19.11.3/examples/skeleton/build/basicfwd)，the function rte_eth_dev_count_avail() returns the ports I bound with dpdk-devbind.py.
I have also installed Suricata-4.1.4 on Ubuntu 16.04 LTS，but when I run suricata，the dpdk ports always returns 0:
So I want to know how can I solve this problem?
Checking the update in the ticket https://github.com/vipinpv85/DPDK_SURICATA-4_1_1/issues/11, the solution is already shared as can you please check if you are using the latest version? If yes please add support for 1G Intel NIC in your environment and update ASAP
hence please add the missing PMD for your use case.
[EDIT-2] the DPDK PMD used for 1G Intel NIC is rte_pmd_e1000
[EDIT-3] had live debug, show case the change to be added for Makfile. Tested and it works
Thanks for vipin's kind help. I have solve this problem successfully.
This is because in dpdk/suricata-4.1.4/src/Makefile, there is only support for i40e. So I add the -lrte_pmd_e1000 -Wl for i350.
(Using STM32F767 microcontroller)
I have a remote debugging environment setup on a RPI using OpenOCD. I can connect to it just fine using GDB.
However since I am writing a bootloader I need to flash the firmware to a specific offset in flash memory. E.g bootloader starts at 0x800000 and firmware should start at 0x8010000 for example so the offset would be (0x10000).
This works fine locally using: mon flash write_bank 0 main.bin 0x10000
But since I don't have the main.bin in the RPI, is there a way I could use OpenOCD or GDB to specify my local file instead and that would be sent over the remote connection?
Note that I would not like to setup a FTP and thus am looking for an alternate solution.
Best regards
gdb should supports sending files to remote via the 'remote put '. But, when I try this in gdb, I get the response "Remote I/O error: Function not implemented". Seems like OpenOCD does not support this
Use "file" to select the file and then "load" will send the file across to the device.
I'm using a Blue Pill board (STM32F103CB with 128kB of flash according to st-info --probe) via a clone ST-Link/V2 like this one. I've also tested using a genuine ST-Link/V2 like this one. I get the same result, described below, with both programmers.
My system is Linux (Debian LXDE) and I've installed OpenOCD from Liviu Ionescu's releases here.
My OpenOCD installation is working. As well as the Blue Pill I have a ST-Nucleo-F103RB board, and I can connect to it using OpenOCD. The command
openocd -f board/st_nucleo_f103rb.cfg
using the standard .cfg file that ships with OpenOCD gives
Open On-Chip Debugger 0.10.0
Licensed under GNU GPL v2
For bug reports, read
http://openocd.org/doc/doxygen/bugs.html
Info : The selected transport took over low-level target control. The results might differ compared to plain JTAG/SWD
adapter speed: 1000 kHz
adapter_nsrst_delay: 100
none separate
srst_only separate srst_nogate srst_open_drain connect_deassert_srst
Info : Unable to match requested speed 1000 kHz, using 950 kHz
Info : Unable to match requested speed 1000 kHz, using 950 kHz
Info : clock speed 950 kHz
Info : STLINK v2 JTAG v29 API v2 SWIM v18 VID 0x0483 PID 0x374B
Info : using stlink api v2
Info : Target voltage: 3.271135
Info : stm32f1x.cpu: hardware has 6 breakpoints, 4 watchpoints
But I still haven't managed to connect to my Blue Pill using the ST-Link/V2 programmers. I've read everything I can find, including relevant sections of https://elinux.org/Category:OpenOCD and as much as I can personally digest of http://openocd.org/doc/. The following is where I've got to.
The .cfg file stm32f103c8_blue_pill.cfg doesn't work for me. It produces the output described below.
Based on what I've read I've prepared my own .cfg file at ../board/stm32f103.cfg. It says:
source [find interface/stlink.cfg]
transport select hla_swd
source [find target/stm32f1x.cfg]
#source [find board/stm32f103c8_blue_pill.cfg]
#reset_config srst_only
#reset_config none separate
Sources I've read suggest this should work, but it doesn't. Using my .cfg described above, it I can use either target/stm32f1x.cfg or board/stm32f103c7_blue_pill.cfg, and I still get the same output as described below. (In the case of both of those .cfg files I'm using the standard files, as shipped with OpenOCD.) I've tested with both of the reset_config variants shown above, and with neither. None of the combinations works.
The file interface/stlink.cfg that I'm using is modified. I've changed it to state the correct device_desc "ST-LINK/V2" and the correct vid_pid 0x0483 0x3748. (Both confirmed using lsusb.) So, ignoring commented lines, stlink.cfg reads
interface hla
hla_layout stlink
hla_device_desc "ST-LINK/V2"
hla_vid_pid 0x0483 0x3748
I've experimented with including the hla_serial of the programmer. Interestingly, lsusb can't find the full serial number. st-info --probe finds the serial number, but gives a slightly different number from the STLinkUpgrade firmware application. I've tried using both serial numbers. No difference.
Here's the command I give to OpenOCD:
openocd -s ~/stm32/openocd/scripts -f board/stm32f103.cfg
Notice that I have to set the path using -s for this command. With the ST-Nucleo-F103RB board, I don't have to do this. With the stm32f103.cfg file, however, if I don't set the path I get:
Error: Can't find board/stm32f103.cfg
in procedure 'script'
If I use the full command shown above, with -s to set the path, I get:
Open On-Chip Debugger 0.10.0
Licensed under GNU GPL v2
For bug reports, read
http://openocd.org/doc/doxygen/bugs.html
/[..]stm32/openocd/scripts/target/stm32f1x.cfg:47: Error: invalid command name "dap"
in procedure 'script'
at file "embedded:startup.tcl", line 60
at file "/[..]stm32/openocd/scripts/board/stm32f103.cfg", line 18
at file "/[..]stm32/openocd/scripts/target/stm32f1x.cfg", line 47
Here's the offending line 47 of stm32f1x.cfg:
dap create $_CHIPNAME.dap -chain-position $_CHIPNAME.cpu
I've searched for items on Stackoverflow/ similar about Error: invalid command name "dap". Using the OpenOCD documentation I understand that the dap create command exists, and roughly what it does. The most similar reported error I've found documented is at https://elinux.org/OpenOCD_Troubleshooting:_Invalid_Command_Name_JTAG, and the solution suggested there doesn't seem to be applicable because I'm not invoking interface/stlink.cfg from the command line.
I can't see what I'm doing wrong, and I'm now completely stuck. If someone can give me a steer I'd be really grateful. Sorry it's such a long post.
I just encountered this problem too. Officially there are no binaries provided, only source code. But there are two sites which release binaries was recommended by OpenOCD official:
1. Maintained by Freddie Chopin.
2. Maintained by Liviu Ionescu in Github.
I tried the latest version(OpenOCD 0.10.0 commit date: 2017-01-22 20:31:28 build date: 2017-01-23) released from Freddie Chopin's site, and I encountered this Error: invalid command name "dap" problem. But all *.cfg files I referenced had ran normally in my another computer with another OpenOCD binary(although I forgot where did I download that binary).
Not sure what went wrong, so I turned to the latest version(gnu-mcu-eclipse-openocd-0.10.0-11-20190118-1134-win64.zip) released by GNU MCU Eclipse(maintained by Liviu Ionescu), the error was gone, problem solved.
PS: I'm not saying there is a bug in Freddie Chopin's build, but if someone encountered this problem, maybe you can solve it by trying the version which is currently under actively maintained.
Agree with Wulfric, using standard install for OpenOCD
sudo apt install openocd
gave the "dap" error.
However the github version openocd-xpack worked correctly.
Using:
Linux clamps 4.15.0-66-generic #75-Ubuntu SMP ... as remote, Windows 8/10 as client target MIMXRT1010-EVK
CONFIGURATION
I have this configuration:
QT Community 5.4.1
dbus-daemon.exe downloaded from http://sourceforge.net/projects/windbus/
link
I have copied in my local directory these qt example:
c:\Qt\Qt5.4.1\Examples\Qt-5.4\dbus\remotecontrolledcar\car
c:\Qt\Qt5.4.1\Examples\Qt-5.4\dbus\remotecontrolledcar\controller
I use Windows 7 and NOT Linux!!!!!!
Procedure:
I compiled both examples in debug mode in my local directory
I launched dbus-daemon.exe with these parameters:
DBUS_SESSION_BUS_ADDRESS sets to tcp; host sets to localhost,port sets to 12434.
set DBUS_SYSTEM_BUS_DEFAULT_ADDRESS=tcp:host=localhost,port=12434
dbus-daemon.exe --session --system --config-file=.\etc\session.conf
I execute car.exe
I execute controller.exe
PROBLEM
The dbus connection fails in particular the method sessionBus form DBusConnection class fails. Infact when i call the isConnected method, it returns false.
Someone can explain why? Is it wrong the way I call the daemon executable?
Or Qt Comunity 5.4.1 have problem with qtdbus? can someone pass me a correct configuration file (session.conf)?
Thank you very much for for the support.
Fausto
On a Windows(R) machine the following function can be used for querying the system power status of the machine:
BOOL WINAPI GetSystemPowerStatus(LPSYSTEM_POWER_STATUS lpSystemPowerStatus);
Is there something similar for a Linux machine?
On most linux systems a daemon named acpid runs all the time monitoring for ACPI events and normally logs info to /var/log/acpid or /var/log/messages. There is a manpage for it at http://linux.die.net/man/8/acpid. acpid stores current ACPI info in /proc/acpi although that's being relocated to /sys somewhere and /sys/power/state holds the current power state seen by catting it (cat /sys/power/state). More info about ACPI is at http://acpi.sourceforge.net/documentation/sleep.html. JCM mentioned a command line tool for ACPI status monitoring named AcpiTool available at http://sourceforge.net/projects/acpitool/. I built that on CentOS and it works fine. Just follow the instructions in its INSTALL file to install it -- it requires a C++ compiler, which is commonly on linux or if not install one using yum or apt.
dmidecode can do many kinds of queries for low level issues including system power supply and controls, see http://linux.die.net/man/8/dmidecode
In collaboration with freedesktop.org RedHat developed and provides DeviceKit-power pre RH7 which is called UPower starting with RH7. It consists of a daemon and command line tool. A manpage for it is at http://www.pkill.info/linux/man/1-upower/. The --dump option of the command line tool provides some useful info but rarely up to date. Maybe restarting the daemon would cause an update. Here is an example of the output from a CentOS 6 host:
ca:17: devkit-power --dump
Device: /org/freedesktop/DeviceKit/Power/devices/line_power_ACAD
native-path: /sys/devices/LNXSYSTM:00/LNXSYBUS:00/ACPI0003:00/power_supply/ACAD
power supply: yes
updated: Tue Dec 23 20:28:27 2014 (866 seconds ago)
has history: no
has statistics: no
line-power
online: yes
Daemon:
daemon-version: 014
can-suspend: no
can-hibernate yes
on-battery: no
on-low-battery: no
lid-is-closed: no
lid-is-present: no
Most major PC vendors such as Dell and HP provide their own apps for power management and monitoring and I've found it is best to use them because they know how to query custom probes designed into the HW and print full diagnostics for their support team.
On My Ubuntu system I found this Information in /sys/class/power_suply/ADP1/online .
For example I used it in a script in an If statement with the following code:
if (( CPUBenutzung > 11 )) || ! (( $(cat /sys/class/power_suply/ADP1/online) )); then Stopmining ; fi
for me this worked fine and stopped the mining process allways when there was no power connected or I did use for some other reason all 12 threads of my notebook.