microsemi / switchtec-user Goto Github PK

Hi,

In #82 @wesleywesley describes the rules to obey to successfully get a PR into this project. Unfortunately they are very different from the ones outlined in CONTRIBUTING.md. If "contributions are most welcome" CONTRIBUTING.md should be updated accordingly to make them happen.

Thanks,
Flössie

Currently the code only support sending raw NVME passthrough data to EPs. This is not user-friendly.

If we can add commands for NVME 1.3 admin commands and enable EPs, then this would server as a reference for user who wants to add other commands for other EPs.

Need to figure out what commands are needed, and their syntax.

Hi, I used this command for Firmware update so I used command :

switchtech fw-update /dev/switchtech0 switchtec_pfx.pmc

is giving
/dev/switchtech0 Input Output Error

Issue:
Running "events" command reports "Invalid argument"

Expected:
Should work successfully and not throw ("Invalid argument")

Please let me know if any further information/debuging info is required.

Thanks

Output currently seen:

# ./switchtec events /dev/switchtec0
event_ctl: Invalid argument

Details follows

Switchtec version

# ./switchtec version
switchtec cli version 4.0

Hardware and firmware details

# cat /sys/class/switchtec/switchtec0/fw_version 
01090063
# cat /sys/class/switchtec/switchtec0/vendor_id 
MICROSEM
# cat /sys/class/switchtec/switchtec0/component_id
PM8532

Debugging session(important parts)
linux_event_ctl() passes for SWITCHTEC_PART_EVT_PART_RESET and SWITCHTEC_PFF_EVT_TLP_THROTTLING. It fails for SWITCHTEC_PFF_EVT_AER_IN_P2P

Breakpoint 1, linux_event_ctl (dev=0x648390, e=SWITCHTEC_PART_EVT_PART_RESET, index=0, flags=0, data=0x0) at lib/platform/linux.c:906
906		if (e >= SWITCHTEC_MAX_EVENTS)


Breakpoint 1, linux_event_ctl (dev=0x648390, e=SWITCHTEC_PFF_EVT_TLP_THROTTLING, index=0, flags=0, data=0x0) at lib/platform/linux.c:906
906		if (e >= SWITCHTEC_MAX_EVENTS)
(gdb) c
Continuing.

Breakpoint 1, linux_event_ctl (dev=0x648390, e=SWITCHTEC_PFF_EVT_AER_IN_P2P, index=197, flags=0, data=0x0) at lib/platform/linux.c:906
906		if (e >= SWITCHTEC_MAX_EVENTS)
(gdb) c
Continuing.
event_ctl: Invalid argument

'mfg' submenu commands do not support access from UART.

Current mfg API functions give error code ERR_UART_NOT_SUPPORTED when called in MAIN boot phase, which is a good way to handle this use case. However, in BL1/2, API functions fail at 'switchtec_open', where it tries to read GAS register to get device ID. The reason is that the GAS registers are not accessible in BL1/2 through UART, so the uart_gas_read() function times out.

It would be better if 'switchtec_open' can return the same ERR_UART_NOT_SUPPORTED if UART is used in BL1/2, but this poses a chicken-and-egg issue: to return this error, we need to determine the current boot phase, and to determine the boot phase, we need to read GAS registers first...

A systemic approach might be needed to fix this issue.

Hi,

when including switchtec.h from a C++ project the compilation fails due to the use of a C++ keyword for a parameter name.

Here's a patch to solve that:

diff --git a/inc/switchtec/switchtec.h b/inc/switchtec/switchtec.h
index d26bb6b..261ec69 100644
--- a/inc/switchtec/switchtec.h
+++ b/inc/switchtec/switchtec.h
@@ -607,8 +607,8 @@ struct switchtec_bwcntr_res {
 	  ingress;			//!< Bandwidth into the port
 };
 
-void switchtec_bwcntr_sub(struct switchtec_bwcntr_res *new,
-			  struct switchtec_bwcntr_res *old);
+void switchtec_bwcntr_sub(struct switchtec_bwcntr_res *new_cntr,
+			  struct switchtec_bwcntr_res *old_cntr);
 int switchtec_bwcntr_set_many(struct switchtec_dev *dev, int nr_ports,
 			      int * phys_port_ids,
 			      enum switchtec_bw_type bw_type);
diff --git a/lib/pmon.c b/lib/pmon.c
index a26f9bf..33f7ffb 100644
--- a/lib/pmon.c
+++ b/lib/pmon.c
@@ -331,21 +331,21 @@ int switchtec_evcntr_wait(struct switchtec_dev *dev, int timeout_ms)
 
 /**
  * @brief Subtract all the values between two bwcntr result structures
- * @param[in,out] new
- * @param[in] old
+ * @param[in,out] new_cntr
+ * @param[in] old_cntr
  *
- * \p new will have it's original values minus all the values in \p old
+ * \p new_cntr will have it's original values minus all the values in \p old_cntr
  */
-void switchtec_bwcntr_sub(struct switchtec_bwcntr_res *new,
-			  struct switchtec_bwcntr_res *old)
+void switchtec_bwcntr_sub(struct switchtec_bwcntr_res *new_cntr,
+			  struct switchtec_bwcntr_res *old_cntr)
 {
-	new->time_us -= old->time_us;
-	new->egress.posted -= old->egress.posted;
-	new->egress.nonposted -= old->egress.nonposted;
-	new->egress.comp -= old->egress.comp;
-	new->ingress.posted -= old->ingress.posted;
-	new->ingress.nonposted -= old->ingress.nonposted;
-	new->ingress.comp -= old->ingress.comp;
+	new_cntr->time_us -= old_cntr->time_us;
+	new_cntr->egress.posted -= old_cntr->egress.posted;
+	new_cntr->egress.nonposted -= old_cntr->egress.nonposted;
+	new_cntr->egress.comp -= old_cntr->egress.comp;
+	new_cntr->ingress.posted -= old_cntr->ingress.posted;
+	new_cntr->ingress.nonposted -= old_cntr->ingress.nonposted;
+	new_cntr->ingress.comp -= old_cntr->ingress.comp;
 }
 
 /**

Best,
Flössie

In the Linux method switchtec_list(struct switchtec_device_info **devlist), should the two occurrences of free(devices[n]); be free(devices[i]); instead?

Following enum overlap the system error number:

ERR_PHYC_PORT_ARDY_BIND = 0x00000001,
ERR_LOGC_PORT_ARDY_BIND = 0x00000002,
…
ERR_BIND_CHECK_FAIL = 0x0000000d,

Which lead to false prompt in case of non-port-bind related commands by following code in switchtec_strerror function:

case ERR_PHYC_PORT_ARDY_BIND:
	msg = "Physical port already bound"; break; 
case ERR_LOGC_PORT_ARDY_BIND: 
	msg = "Logical bridge instance already bound"; break; 
    …
case ERR_BIND_CHECK_FAIL: 
	msg = "Port bind checking failed"; break;

Originally posted by @wesleywesley in #42 (comment)

Using fw-update on i2c device fails with error code 0x11 with error message "firmware update: Programming not allowed over this interface". It seems to fail in 'switchtec_fw_wait' in the do-while loop, after a couple iterations the 'switchtec_fw_dlstatus' returns a status of 0x11. It seems to always fail after 4/5 iterations in this loop.

other commands like 'info', 'status', 'test', 'fw-info', etc. work on this device.

Here's the full error:

# switchtec fw-update /dev/i2c-10@0x10 ./switchtec_image.data
Writing the following firmware image to /dev/i2c-10@0x10.
File:           switchtec_image.data
Gen:            GEN4
Type:           MAP
Version:        1.0
Img Len:        0x100
CRC:            0xabcdabcd
Secure version: 0x00000000
Do you want to continue? [y/N] y
   0% [>                                                                                                                                            ] ETA:  0:26:50    5kB/s
firmware update: Programming not allowed over this interface
#

How does the switchtec driver translate the addresses between two CPU’s or two hosts? How do the two switches figure out the address translations between the first switch’s CPU’s/host’s addresses on the upstream ports, through the NT Only port, to the second switch’s NT Only port, back up to the second switch’s upstream port?

when I try make in the Ubuntu 20.04.4 LTS (GNU/Linux 5.4.0-124-generic x86_64);
it show the error as follow:
cli/commands.c:27:10: fatal error: version.h: No such file or directory
27 | #include "version.h"
| ^~~~~~~~~~~
how can I fix it?

Please start making release tags in the git repo for releases. Putting a release number in just the header of a github "release" is not really sufficient. For instance, if we look at the release titled "Switchtec-user v2.6 Release for Switchtec Gen4 PFX/PSX/PAX MR3", we would see that the tag for that release is actually "v2.6-rc1", which would lead us to think it is a "release candidate" rather than a proper release". Further, the URL for that release page is "https://github.com/Microsemi/switchtec-user/releases/tag/v2.6-rc1", and the tarball in the "assets" for that release have the version as "v2.6-rc1". This makes it more difficult than it needs to be for those of us trying to build packages for these releases.

What we really want is a "v2.6" release tag, without the "rc". The github release should then be based on that. If you make the "v2.6" and annotated tag, you can put the release notes right in the commit message for the tag as well.

I am seeing the following error when using a 5.8.15-301.fc33.x86_64 kernel and the latest switchtec user/driver:

./switchtec gas read 0 -a 0x2104 -b4
gas_map: Invalid argument

When we use an older kernel, we do not see this problem. In order to get the kernel driver to compile on 5.8, I had to change "pci_cleanup_aer_uncorrectable_error_status(pdev)" to "pci_aer_clear_nonfatal_status(pdev)".

Hello, i am experiencing strange behavior trying to read temperature over serial/mmapped interface:

Results in zero read with no visible error:

./switchtec gas write /dev/switchtec0 -a 0x0 -v 0x2 -y
./switchtec gas write /dev/switchtec0 -a 0x800 -v 0x04 -y
./switchtec gas read /dev/switchtec0 -a 0x400
000400 - 0x00000000

./switchtec gas write /dev/ttyUSB0 -a 0x0 -v 0x2 -y
./switchtec gas write /dev/ttyUSB0 -a 0x800 -v 0x04 -y
./switchtec gas read /dev/ttyUSB0 -a 0x400
000400 - 0x00000000

Same sequence over terminal by hand gives expected result:

0x00000000:004f>gaswr 0x0 0x2
gas_reg_write() success
0x00000000:0050>gaswr 0x800 0x04
gas_reg_write() success
0x00000000:0051>gasrd 0x400
gas_reg_read <0x400> [1]
0x000011bd
0x00000000:0052>

tested on v2.6-rc1

It's been some months without a new release and some fixes have landed to the tree. Any plans to make a new release?

Hi,
I'm trying to use the PCI bdf address instead of /dev/switchtec0, but got below the error saying "operation not supported".

Here are the logs:

root@debian10-> switchtec version
switchtec cli version 2.0
root@debian10-> switchtec list
switchtec0 3.50 BF40 0000:17:00.1
switchtec1 3.50 BF40 0000:19:00.1
switchtec10 3.50 BF40 0000:ca:00.1
switchtec11 3.50 BF40 0000:cc:00.1
switchtec12 3.50 BF40 0000:e3:00.1
switchtec13 3.50 BF40 0000:e5:00.1
switchtec2 3.50 BF40 0000:31:00.1
switchtec3 3.50 BF40 0000:4b:00.1
switchtec4 3.50 BF40 0000:4e:00.1
switchtec5 3.50 BF40 0000:65:00.1
switchtec6 3.50 BF40 0000:67:00.1
switchtec7 3.50 BF40 0000:98:00.1
switchtec8 3.50 BF40 0000:b1:00.1
switchtec9 3.50 BF40 0000:b3:00.1
root@debian10-> switchtec info /dev/switchtec0
/dev/switchtec0:
Generation: GEN4
Variant: PFX
Device ID: 0x4000
FW Version: 3.50 BF40
root@debian10-> switchtec info 17:00.1
/dev/switchtec0
17:00.1: Operation not supported
root@debian10-> switchtec info 0000:17:00.1
/dev/switchtec0
0000:17:00.1: Operation not supported

Traced the code, and I know it eventually finds the switchtecX name and use /dev/switchtecX for the operation, but somehow it didn't work.

Is there anything I should check?

We are hitting "firmware update: Unknown Error (16)" error on upgrading fw and config file.

Use following commands through a script.
switchtec fw-update ${SW_DEV} ${fw_file} -y > /dev/null
switchtec fw-update ${SW_DEV} ${cfg_file} -y > /dev/null

Any idea what is err 16 (EBUSY ?) trying to upgrade fw and config file ?

Hi,

Can we access this same endpoint by two hosts at same time.

This switch has SR-IOV feature but this will work only with multiple virtual machines running on single root and of course endpoint should have SR-IOV support.

But we are looking for multiple host communicating with same endpoint.
Any suggestions?

Thanks,
Hardik

Hey guys,

do you think its possible to access TWI recovery over Windows somehow?

I tried to access via WSL2 and switchtec kernel. I needed to bind the USB-I2C device to the WSL2 but cannot get a connection to the device.

Do you think there is a possible workaround ?

To reproduce run : switchtec status /dev/switchtec1
Only few device info appear.
The parsing of sysfs seems to be wrong.

Here is the fix:

switchtec-issue7.log

We run into the following issue when trying to compile in linux.
One workaround is to remove libi2c-dev, but it seems the issue is the way it includes i2c-dev.h and i2c.h.

switchtec-user# make
  CC    lib/platform/linux-i2c.c
In file included from lib/platform/linux-i2c.c:46:0:
/usr/include/linux/i2c-dev.h:37:8: error: redefinition of 'struct i2c_msg'
 struct i2c_msg {
        ^
In file included from lib/platform/linux-i2c.c:45:0:
/usr/include/linux/i2c.h:68:8: note: originally defined here
 struct i2c_msg {
        ^
In file included from lib/platform/linux-i2c.c:46:0:
/usr/include/linux/i2c-dev.h:90:7: error: redefinition of 'union i2c_smbus_data'
 union i2c_smbus_data {
       ^
In file included from lib/platform/linux-i2c.c:45:0:
/usr/include/linux/i2c.h:129:7: note: originally defined here
 union i2c_smbus_data {
       ^
lib/platform/linux-i2c.c: In function 'i2c_msg_pec':
lib/platform/linux-i2c.c:87:14: warning: pointer targets in passing argument 1 of 'crc8' differ in signedness [-Wpointer-sign]
  return crc8(msg->buf, byte_count, pec, false);
              ^
In file included from lib/platform/linux-i2c.c:28:0:
lib/platform/../crc.h:34:9: note: expected 'uint8_t * {aka unsigned char *}' but argument is of type 'char *'
 uint8_t crc8(uint8_t *msg_ptr, uint32_t byte_cnt, uint32_t oldchksum,
         ^
lib/platform/linux-i2c.c: In function 'i2c_gas_cap_get':
lib/platform/linux-i2c.c:224:14: warning: pointer targets in assignment differ in signedness [-Wpointer-sign]
  msgs[0].buf = &command_code;
              ^
lib/platform/linux-i2c.c:228:14: warning: pointer targets in assignment differ in signedness [-Wpointer-sign]
  msgs[1].buf = rx_buf;
              ^
lib/platform/linux-i2c.c: In function 'i2c_gas_data_write':
lib/platform/linux-i2c.c:303:10: warning: pointer targets in assignment differ in signedness [-Wpointer-sign]
  msg.buf = (uint8_t *)i2c_data;
          ^
lib/platform/linux-i2c.c: In function 'i2c_gas_write_status_get':
lib/platform/linux-i2c.c:340:14: warning: pointer targets in assignment differ in signedness [-Wpointer-sign]
  msgs[0].buf = &command_code;
              ^
lib/platform/linux-i2c.c:344:14: warning: pointer targets in assignment differ in signedness [-Wpointer-sign]
  msgs[1].buf = rx_buf;
              ^
lib/platform/linux-i2c.c: In function 'i2c_gas_data_read':
lib/platform/linux-i2c.c:470:14: warning: pointer targets in assignment differ in signedness [-Wpointer-sign]
  msgs[0].buf = (uint8_t *)read_command;
              ^
lib/platform/linux-i2c.c:475:14: warning: pointer targets in assignment differ in signedness [-Wpointer-sign]
  msgs[1].buf = (uint8_t *)read_response;
              ^
lib/platform/linux-i2c.c: At top level:
cc1: warning: unrecognized command line option '-Wno-initializer-overrides'
Makefile:114: recipe for target 'build/lib/platform/linux-i2c.o' failed
make: *** [build/lib/platform/linux-i2c.o] Error 1

function switchtec_fw_write_fd() should not perform operation
cmd.hdr.dont_activate = !!dont_activate;
before downloading the image, as it the image is toggled regardless of whether the operation completes successfully.

I just noticed somebody is setting executable bits on source files when they should not be. These are hard to catch in reviews, can somebody clean that up and try to make sure it doesn't continue to happen:

-rwxr-xr-x 1 gunthorp gunthorp   3343 Feb  7 12:59 ./cli/common.h
-rwxr-xr-x 1 gunthorp gunthorp  53857 Feb  7 12:59 ./cli/main.c
-rwxr-xr-x 1 gunthorp gunthorp  32269 Feb  7 12:59 ./cli/mfg.c
-rwxr-xr-x 1 gunthorp gunthorp   1993 Feb  7 12:59 ./config.h.in
-rwxr-xr-x 1 gunthorp gunthorp   1092 Feb  7 12:59 ./configure.ac
-rwxr-xr-x 1 gunthorp gunthorp   2349 Feb  7 13:02 ./inc/switchtec/errors.h
-rwxr-xr-x 1 gunthorp gunthorp   5827 Feb  7 12:59 ./inc/switchtec/mfg.h
-rwxr-xr-x 1 gunthorp gunthorp   4627 Feb  7 12:59 ./inc/switchtec/mrpc.h
-rwxr-xr-x 1 gunthorp gunthorp  28254 Feb  7 13:05 ./inc/switchtec/switchtec.h
-rwxr-xr-x 1 gunthorp gunthorp   6902 Feb  7 12:59 ./lib/crc.c
-rwxr-xr-x 1 gunthorp gunthorp   1585 Feb  7 12:59 ./lib/crc.h
-rwxr-xr-x 1 gunthorp gunthorp  39217 Feb  7 12:59 ./lib/fw.c
-rwxr-xr-x 1 gunthorp gunthorp  21767 Feb  7 13:12 ./lib/mfg.c
-rwxr-xr-x 1 gunthorp gunthorp  15209 Feb  7 12:59 ./lib/platform/linux-i2c.c
-rwxr-xr-x 1 gunthorp gunthorp  12114 Feb  7 13:08 ./lib/platform/linux-uart.c
-rwxr-xr-x 1 gunthorp gunthorp  24161 Feb  7 13:03 ./lib/switchtec.c
-rwxr-xr-x 1 gunthorp gunthorp   7089 Feb  7 13:08 ./lib/switchtec_priv.h
-rwxr-xr-x 1 gunthorp gunthorp   5753 Feb  7 12:59 ./Makefile.in

Is there a way to check if an issued command was successful?

Thanks,
Dan

When applying ./configure --prefix=/opt/switchtec and then running make and sudo make install, the software is installed to /usr/local/bin.

This was not my installation directory.

Hi,

Using ./switchtec status 0 command, the data for a populated slot will include the device information only in the queried partition management EP.
In the below example, information exists for partition 0 logical port 25 - The device is nvme4.
But for partition 1 (which is UPS only) there is no device information.

Partition 0:
Logical Port ID 25 (DSP):
Phys Port ID: 40 (Stack 5, Port 0)
Bus-Dev-Func: 0000:3a:18.0
Status: UP
LTSSM: L0
Max-Width: x2
Neg Width: x2
Rate: Gen3 - 8 GT/s 1.97 GB/s
Out Bytes: 289 kB
In Bytes: 3.01 MB
ACS: P2P Redirected
Device: 11f8:8606 (0000:53:00.0)
nvme4

Partition 1:
Logical Port ID 2 (DSP):
Phys Port ID: 17 (Stack 2, Port 1)
Status: UP
LTSSM: L0
Max-Width: x2
Neg Width: x2
Rate: Gen3 - 8 GT/s 1.97 GB/s
Out Bytes: 99.1 kB
In Bytes: 2.82 MB

Can you please add the device information regardless of the queried management EP and the partition to which it belongs?

Hi,
Any idea what may cause the following failure? (I'm trying to burn from Linux the same image that I burn from serial using switchlink).

Currently Running:
  IMG Version: 1.09 B063
Active Partition:
  BOOT 	Version: 1.09 B063	CRC: e8d37467   (RO)
  MAP 	Version: 1.09 B063	CRC: 523ced6e
  IMG  	Version: 1.09 B063	CRC: 23d057bf	(Running)
  CFG  	Version: 1.09 B063	CRC: d1049752	(Running)
   	Multi Config 0
   	Multi Config 1 - Active
Inactive Partition:
  IMG  	Version: 1.09 B063	CRC: 23d057bf
  CFG  	Version:         	CRC: ffffffff
[vastdata@localhost ~]$ sudo switchtec-user/switchtec fw-update switchtec0 Sep18/vast_2.0_x96.pmc
Writing the following firmware image to switchtec0.
File:     vast_2.0_x96.pmc
Type:     DAT
Version:  1.09 B063
Img Len:  0x9c18
CRC:      0xbef280fc
Do you want to continue? [y/N] y
 100% [================================================================================================================] ETA:  0:00:00   37kB/s
firmware update: Unknown Error (1)
[vastdata@localhost ~]$

Greetings switchtec-user developers and contributors,

We’re reaching out because your project is an important part of the open source ecosystem, and we’d like to invite you to integrate with our fuzzing service, OSS-Fuzz. OSS-Fuzz is a free fuzzing infrastructure you can use to identify security vulnerabilities and stability bugs in your project. OSS-Fuzz will:

• Continuously run at scale all the fuzzers you write.
• Alert you when it finds issues.
• Automatically close issues after they’ve been fixed by a commit.

Many widely used open source projects like OpenSSL, FFmpeg, LibreOffice, and ImageMagick are fuzzing via OSS-Fuzz, which helps them find and remediate critical issues.

Even though typical integrations can be done in < 100 LoC, we have a reward program in place which aims to recognize folks who are not just contributing to open source, but are also working hard to make it more secure.

We want to stress that anyone who meets the eligibility criteria and integrates a project with OSS-Fuzz is eligible for a reward.

If you're not interested in integrating with OSS-Fuzz, it would be helpful for us to understand why—lack of interest, lack of time, or something else—so we can better support projects like yours in the future.

If we’ve missed your question in our FAQ, feel free to reply or reach out to us at [email protected].

Thanks!

Tommy
OSS-Fuzz Team

Sir,

In release 1.1 rc1, switchtec.c, in the function call to retrieve port status, (command: "switchtec status"), one can change the second argument of the call to ltssm_str to 1, to enable display of ltssm minor states.
s[p].ltssm_str = ltssm_str(s[i].ltssm, 0);

However, the correct ltssm minor state is not displayed. This is due to the ltssm variable declaration in switchtec.h not being long enough to hold both the major and the minor information. When the change below is made, switchtec status shows the correct minor state.

diff --git a/inc/switchtec/switchtec.h b/inc/switchtec/switchtec.h
index 39fc567..c9d8a06 100644
--- a/inc/switchtec/switchtec.h
+++ b/inc/switchtec/switchtec.h
@@ -109,7 +109,7 @@ struct switchtec_status {
unsigned char neg_lnk_width; //!< Negotiated link width
unsigned char link_up; //!< 1 if the link is up
unsigned char link_rate; //!< Link rate/gen

• unsigned char ltssm; //!< Link state

• uint16_t ltssm; //!< Link state
  const char *ltssm_str; //!< Link state as a string
  char *pci_dev; //!< PCI BDF of the port

Could you please confirm the change and roll it into the mainline code?

Right now in gui mode we do not handle resizing of the terminal window. Address this uses the standard approaches recommended in ncurses usage.

Our I2C master is smbus only so the userspace library is dying since it only relies on I2C commands.
Can you add the support for smbus protocol as well?

We're seeing crashes with "switchtec status /dev/switchtec0".

I've traced the issue part way to this code:

lib/switchtec.c:
static void generate_lane_str(struct switchtec_status *s)
{
int i, l;

for (i = 0; i < s->cfg_lnk_width; i++)
	s->lanes[i] = 'x';

If cfg_lnk_width is > 16, there's a buffer overrun while writing "x".

At the moment, however, I don't know why cfg_lnk_width is garbage. It's possible that the problem is local to our hardware. It bothers me that every one doesn't see this. :-)

I have been trying to debug an issue I am facing with "info" command with little luck. Can anyone help me chase down an issue I am facing. The details are given below and any futher info required please let me know.

Thanks

Issue.
I am getting "Bad message" on my device when issuing an "info" command

# ./switchtec info /dev/switchtec0
dev info: Bad message

Details follows

This is the version I am using.

# ./switchtec version
switchtec cli version 4.0

Device test output

# ./switchtec test /dev/switchtec0
test: success

Debugging session analysis :

My understanding is that read_resp() will have first 4 bytes as return value. Followed by variable length data.
I could see that it is returning 0x00000000, however it is still failing with -1. Where is it going wrong.

(gdb) x /12x buf
0x7fffffffde70:	0x00000000	etc...

More detailed debugging session(important parts)

(gdb) s
read_resp (resp=resp@entry=0x7fffffffdf58, resp_len=resp_len@entry=8, ldev=<optimized out>) at lib/platform/linux.c:331
331	    size_t bufsize = sizeof(uint32_t) + resp_len;
(gdb) n
332		char buf[bufsize];
(gdb) 
334		ret = read(ldev->fd, buf, bufsize);
(gdb) p ldev->fd
value has been optimized out
(gdb) p bufsize
$19 = 12
(gdb) n
336		if (ret < 0)
(gdb) p ret
$20 = -1
(gdb) x /12x buf
0x7fffffffde70:	0x00000000	0x63592f39	0x00179ec8	0x00000000
0x7fffffffde80:	0xffffdf28	0x00007fff	0xf7fe76c0	0x00007fff
0x7fffffffde90:	0xffffdec0	0x00007fff	0x00000008	0x00000000
(gdb) n
353		return ret;
(gdb) n
switchtec_cmd (dev=dev@entry=0x648330, cmd=4294705408, cmd@entry=256, payload=payload@entry=0x7fffffffdf54, payload_len=payload_len@entry=4, 
    resp=resp@entry=0x7fffffffdf58, resp_len=resp_len@entry=8) at lib/platform/platform.c:174
174		if (ret > 0) {
(gdb) p ret
$26 = -1
(gdb) n
179		return ret;
(gdb) n
switchtec_get_device_info (dev=dev@entry=0x648330, phase=phase@entry=0x0, gen=gen@entry=0x0, rev=rev@entry=0x7fffffffdf9c) at lib/switchtec.c:1750
1750		if (ret == 0) {
(gdb) p ret
$27 = -1
(gdb) n
1761		} else if (ERRNO_MRPC(errno) == ERR_CMD_INVALID) {
(gdb) n
print_dev_info (dev=0x648330) at cli/main.c:203
203		if (ret) {
(gdb) p ret
$28 = -1
(gdb) n
info (argc=<optimized out>, argv=<optimized out>) at cli/main.c:232
232		return print_dev_info(cfg.dev);
(gdb) n
dev info: Bad message
205			return ret;
(gdb) 

switchtect required a log-def file to parse log_dump, but we don't know how to get the log def file
our device is PM40052-PFX

Right now in gui mode there are a couple of places where we call switchtec_perror before pulling down the ncurses windows. Thei can lead to garbage on the screen. Clean up those cases perhaps with a gui_exit() handler.

The Makefile doesn't configure the libraries that are created.
One has to specifically do ldconfig /usr/local/lib to get the libraries installed.
there are lines with LDCONFIG in the makefile but the libraries aren't configured.
Not about to try and fix the makefile as I don't want to screw it up.
Who ever did this probably configured them by hand and didn't remove them when they tested the makefile. I found this by trying to build and run examples/temp

Hi, Guys,

GUI command invoke "switchtec_bwcntr_set_many()" firstly in gui_init() of gui_main(), it clear/reset the bw cntr as a by-product besides setup bw cntr mode (raw/payload).
For this reason, the followed "switchtec_bwcntr_many()" w/ reset is unnecessary.

From the user point of view, "-r" option confuse customer, because w/ or w/o this option, the results is identical. ("-r" option and button press of "r" at runtime are two different things)

Suggesting remove "-r" option gui command from its argument list.

Regard,
Wesley

Hi,
I'm looking for a way to add a version number to switch configuration..
Switchtec 'fw-info' command shows something called 'CFG Version' (see below).
Is there a way to control it from Chiplink?

Thanks,

Dan

$ sudo switchtec/switchtec fw-info switchtec0
Currently Running:
IMG Version: 1.09 B063
Active Partition:
BOOT Version: 1.09 B063 CRC: e8d37467 (RO)
MAP Version: 1.09 B063 CRC: a07c6f51
IMG Version: 1.09 B063 CRC: 23d057bf (Running)
CFG Version: 1.09 B063 CRC: e36b0e27 (Running)
Multi Config 0
Multi Config 1 - Active
Inactive Partition:
IMG Version: 1.09 B063 CRC: 23d057bf
CFG Version: 1.09 B063 CRC: bef280fc

Hi,

How to know If hot plug feature is enabled or not in switch?

Thanks,
Hardik

The API page on
https://microsemi.github.io/switchtec-user/
only shows API version 0.9-rc2.

@lsgunth what tools did you use to generate documents? Maybe I can use the same tool to update API documentation and push to gh-pages.