Hi, Soumyajyotii Ssarkar <[email protected]> writes:
> Dear Sven Schnelle, > I am Soumyajyotii Ssarkar. I am working on developing the LASI's 82596 > NIC and the NCR710 SCSI controller device model > for the PA-RISC machines in QEMU under the guidance of Helge. > I have been debugging the 82596 NIC. So far, we have implemented most > of the functionality for the Linux Kernel side. > > However, after some trials and tribulations, we got it working on the > HPUX 10.20 side also.As of now, the transmit and > receive functions are not working on the HPUX 10.20 side. > I wanted to debug the issue where the HPUX 10.20 is getting stuck and > what is happening on the driver side. So far, I > have been using GHIDRA to look at the HPUX 10.20 lan drivers > (liblan.a) however, the code from the GHIDRA side is a bit > obfuscated, and I can only understand certain things. > For example: > > In the liblan.a (HPUX 10.20 kernel side drivers) > in lan2.o using ghidra: > > we see the string "82596 failed to pass its self test" > > When I try to backtrack and look at the references to the string I > don't find any references to the string when reverse engineering with > ghidra. The code is likely using a base address + offset to access memory. It's been a while, but usually it's using something like: ldil L%12345678,%r1 ldo R%12345678(%r1),%r1 That pair is usually decoded by ghidra, but if the ldil is done in a different function ghidra might not know that constant value in r1. In that case you can tell ghidra about the constant value in %r1. You can do that by going to an instruction (or select multiple instructions) and pressing 'R' which opens a popup window. In that window you can preset registers with values. You need to figure out that offset with gdb by breaking execution and looking at registers. But it really depends on the code generated - it's hard to give some general answer here. > But when using the HPUX 10.20 if I do, lanadmin -> ->lan -> reset -> > it does printk the "82596 failed to pass its > self test" > Similarly, their are strings like: > "82596 could not be configured with LPBK mode", > "82596 bug; EOF or Final bit in RFD not set; resetting the LAN > driver" > with no references in any functions, from what I understand using > ghidra. Are watchpoints working in qemu? If yes you could set a ro watchpoint to the string and see where it breaks. Usually that's some strcpy like function, so you need to do some stack unwinding to see where the code was called from. Another way is to find the generic printk like function which prints all those warnings and break at that function. Same again, you need unwinding and find the caller of this function then. > Similarly for the Transmit and Receive function we are although not > seeing any errors but the function itself is not > working on HPUX, so I was looking forward to understanding the HPUX > 10.20 driver side more so we could properly upgrade > the Transmit and Receive function in our QEMU device model to work > with HPUX 10.20. > > I would like to ask for your guidance on how I could better debug and > understand what is happening on the HPUX 10.20 > kernel side. > And debug the HPUX kernel drivers better to get our 82596 working on > the HPUX 10.20. > I was going through your code for the Tulip in QEMU, which was working > perfectly on the HPUX 10.20 and would like to ask > you: > > 1 How did you debug the HPUX kernel side while developing the Tulip > NIC? Honestly i don't remember how hard it was to get it running with HP-UX. The only thing i remember was 53c710 because that was much more complicated. > 2 What does the HPUX kernel side expect? Is there any kind of pattern > for obfuscation in the HPUX kernel for the NIC drivers? No. PA-RISC is already hard enough to read for most people, no obfuscation needed :-) > 3 What could the HPUX 10.20 expect in the Kernel side for the Recieve > and transmit function in general? > 4 Based on the above issues with transmit and receive not working, > what could I do to move forward with debugging and > fixing it? As written above, hard to say. The only thing i can say about using ghidra is ignore the decompiler for PA-RISC. HPPA with it's conditions on most of the instruction and a delay slot is very hard for the decompiler. I never seen really useful code from the decompiler, and sticked to reading disassembly or instruction traces. There's also an instruction tracer plugin in qemu. That generates tons of logfiles, but sometimes this is the only way to follow code flow. What i also did was to patch qemu to generate a gdb break point from driver code to see where the kernel is accessing hardware. But i can't recall what the function was to do that. Regards Sven
