I’m looking to do some kernel mode debugging using a network cable.
Exactly what kind of cable is required ? Will a straight-through cable work or do I need a special cable to accomplish this ?
Any proper cable should do - category 5e or better for 100 or 1000 Mbit/s aka 100BASE-TX or 1000BASE-T.
A straight standard patch cable should be fine. If you don't use a switch in between, the link should come up all the same, as Auto MDI-X (auto crossover) is nearly ubiquitous. If the link doesn't come up you'll need a crossover cable or adapter.
Related
I have a costume board with Xilinx Zynq UltraScale+ RFSoC.
I'm using 3 PS_GTR transceivers as sgmii.
2 of them are connected to external Marvell phy and the third connects directly (fixed link - without phy).
In the manufacturing stage i would like to make sure that the direct sgmii interface is assembled correctly - so I made an external loopback between tx and rx sgmii signals.
Now, Is it possible to transmit something through this external loopback and compare with the received data?
Is it possible to ping with yourself? (simple ping command not working: "ping -I eth2 ")
perhaps there is a 'patch' under the 'macb' kernel driver that someone can guide me through?
Thank you all,
Tzipi Kluska
Yes it is possible to ping yourself. Note that linux does or at least used to bypass the hardware when talking to itself and would do the loopback in the IP stack. I recently saw someone within a terminal (window, command line) isolate one network interface, then another another network interface and then it was trivial to use stock tools like ping and iperf to test the link.
Before doing that though, the serdes on your part should have PRBS capabilities (for a reason), some may have internal scope like features that allow you to extract an eye or at least numbers that indicate the quality of the eye. The marvell phy should also have this capability and you can both use a loopback to talk to yourself use various prbs lengths to check the quality of the link (less than one error in so many 10 to the 14th bits or whatever your desired quality is), and then when connected to the marvell repeat that.
Before doing all of this the software is often the hard part and you need to insure you have it working first, so you may wish to do loopbacks inside the fpga that do not have analog issues and get the software worked out, then in the serdes on the edge of the fpga they may have loopbacks in both directions, the marvell as well may have loopbacks in both directions so you can for example go direct fpga to marvell one is the tx and one the rx and vice versa, or you might enable a lan side shallow loopback on the marvell and talk to yourself.
Also depending on these speeds, hand made loopbacks might be noisy so sometimes a pcb based loopback (which also has to be designed) may wish to be deployed.
Can you ping yourself, absolutely. You can use other low level network interfaces like sockets, to make raw packets and talk to yourself through these interfaces as well. Ping, doing a ping flood, iperf, netperf, etc are all fine ways to exercise or get a warm fuzzy about the interface during both development and manufacture test.
Being an fpga you can of course have a test design that you load into the fpga that pushes the external interfaces and reports the bit error rate.
I am trying to learn Linux by following instructions in "Mastering Embedded Linux Programming" by Chris Simmonds. By following the book and with some help from Stack_Overflow_1, i was able to build the MLO and u-boot.img.
However, when i connect USB cable to my PC and execute the ls /dev/tty* command, i cannot find any device with /dev/ttyUSB. All i can see are devices with /dev/tty0-63, /dev/ttyS0-31 and one /dev/ttyprintk.
Also, when i press down the S2 button and connect the USB cable, i can only see the power led glowing and nothing else.
I have properly built the u-boot (three attempts to get it right).
Also, as per the instructions in the book, i am only testing the u-boot stuff and yet to reach the kernal part.
If i remove the sd card and connect the USB, im an able to talk to my BBB over ssh (192.168.7.2).
How to i get the u-boot to work? Thank you!
If you don't have one yet, I'd recommend to get a USB-to-serial device (3.3V Vref). You connect it to the debug UART (J1) which is located next to the P9 side. Nowadays those are very cheap and can cost below 1$. Ones that feature a genuine FTDI part will be 5-10$ at least.
The serial port you are referencing is only available once the device has passed through U-Boot, booted the kernel and finally userspace has set up the communications.
Especially when working with U-Boot and the Kernel, low level UART access is crucial.
As a further note, could it be that the Book refers to the (white) original Beaglebone? That has a FTDI USB-to-UART chip on board and will allow you even U-Boot access. You can do the same things if you have the above mentioned USB device.
https://groups.google.com/g/beagleboard/c/eNDjK05spY8/m/GPvhcP52BAAJ shows that one needs to hold the space key to enter u-boot.
Also, the info. here might be more up to date compared to the book.
https://www.digikey.com/eewiki/display/linuxonarm/BeagleBone+Black
There is no way to copy and paste everything from the eewiki. I just left you the link. Enjoy!
I would like to control some physical engines, switches on/off, lights through a self written C API.
I already have a very general overview of how to achieve this:
Use the kernels abstraction, write a driver on it and use this as control. The driver itself has to manage incoming bytes and interpret them (depends on port).
I personally would prefer to use a USB port because I can use my MacBook to develope.
But I know that the protocol is quite complicated. However here are my specific questions:
Which port is good to use (is USB a suitable option?)
Could I simply wire a engine to the USBs power cables and connect the data cables to a power swith or do I require an extra board?
Are there better docs for OS X, BSD or gnu/Linux?
Bodo
To control physical engines, you have to add at least a power supply board, there is no way that your USB port drive a DC motor (maybe a LED).
The easiest I/O port on a computer is the LPT (parallel port), but this is a 'very' old thing. I agree that USB port is most convenient but in order to work easily with it I advise you to buy a small card.
This Usb board (or anything of the same kind) can do the trick.
I hope it could help you,
I have successfully talked to the computer from an Arduino via serial USB port and I had the idea that I could make a keyboard or mouse with the arduino. Say I wanted to translate the computer's mouse 1 pixel to the left. What message would I have to send over the serial line in order to achieve this?
Google is a wonderful thing. "use arduino as mouse" returns 1.7 million hits. The third hit on the list takes you to the Arduino Playground for an example using the new Leonardo board.
Note:
The Leonardo differs from all preceding boards in that the ATmega32u4 has built-in USB communication, eliminating the need for a secondary processor. This allows the Leonardo to appear to a connected computer as a mouse and keyboard, in addition to a virtual (CDC) serial / COM port.
Assuming you don't have that board, here is another site for some other specific boards and yet another that is log for a project including hardware and software for older boards.
Hope this helps (and is a better answer to the question).
You would have to reconfigure the USB interface chip to appear as a USB HID endpoint.
I am doing IO programming in C in Ubuntu. And I need the base address of the port to write data.
My laptop dont have a parallel port. So I bought a USB to Parallel port connector. I plugged in the device and its getting detected in /dev/usb/lp0
I ran "lsusb" to see the list of devices and I can see the ID also. But how can I get the base address ? For the usual hardware parallel devices, the base address is 0x0378. this address is not getting detected while using USB to Parallel device.
Please help.
A USB parallel port doesn't have a base address - it's not a meaningful concept for USB. I'm afraid the days of doing I/O on PC hardware via in and out instructions ended a few years ago, though lots of old tutorials still survive on the web.
You can write bytes to the parallel port as a character device, and these will appear on the printer port pins. The USB adapter will expect the other end to handshake data exactly like a printer. If you want to do general I/O prototyping, you're probably better off with a simple USB microcontroller like an Arduino.
Further discussion here.
If you are still interested to use this USB-to-parallel-printer device for your own bit-banging, it's important to know that their built-in firmware always allows controlling of D0..D7, INIT (as outputs), /ERR, ONL, PE (as inputs), but never for /ACK, BUSY (inputs), /STB, /AF, /SEL (outputs) pins.
And you need an 8-bit latch (e.g. 74HCT574) for catching data while strobing.
See here (https://www-user.tu-chemnitz.de/~ygu/bastelecke/PC/USB2LPT/faq#DIY)
especially for possible data rates.
Accessing from software side is a bit complicated but possible, and you may have to re-structure your software and hardware for making such adapters useable. I don't know for Linux case how to access, but IMHO you don't need to write a kernel-mode driver.