With freshly flashed L4T 21.8, the serial console stops with output like:
## Flattened Device Tree blob at 82000000
Booting using the fdt blob at 0x82000000
Using Device Tree in place at 82000000, end 83014f2d
Starting kernel ...
How do I get serial output from the kernel?
When things stop after "Starting kernel...", across boards, there are usually two causes:
serial console isn't enabled right
kernel didn't have enough space to unpack itself and start printing to serial console.
The first thing to enable is serial console. Make sure the kernel command line for TK1 includes:
console=ttyS0,115200n8 earlycon=uart8250,mmio32,0x70006300 earlyprintk
Two things are going on there: One is enabling normal serial console once boot gets far enough. The other is enabling earlycon before the proper 8250 driver is initialized, so you can see early boot failures too. This serial setup should get you output on the DB9 connector J1A2 (UART4) just like u-boot uses.
If you still don't have serial output with that, likely the issue is the kernel trashing the dtb while unpacking -- the default 16Mb between 0x81000000 kernel and 0x82000000 fdt is not enough for many kernels. You need to move the fdt address up to make space. Press the reset button, and interrupt the boot by pressing a key when prompted, then enter this in your u-boot command line:
set fdt_addr_r 0x83000000
saveenv
run bootcmd
This gets you 32MB of space for the kernel image for this boot, and thanks to saveenv also any following ones.
Related
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!
There are some cases when it is needed to see the full log of Linux kernel panic.
But it often can't be done through the regular terminal in display.
I thought that it should be done through the COM-port, but can't figure out:
How can I do that?
What is the reason of working well through COM-port, but not through terminal in my display?
UPD: I use debian-based custom Linux (4.9 kernel) with HDMI-display.
Related: How to get a Linux panic output to a USB serial console when system has also a display adapter
Simple direct connected console / VTY use the graphics card to convert character bytes (0 - 255) into display character cells. 80x25 is a common format. This is very simple and not hard for a crashing kernel to manage. Just copy some memory around.
The graphical console is more complicated because the kernel now has to locate the font bitmap for a character and copy the bitmap onto the display. It also needs to handle scrolling with more memory copies, or IOCTL calls into the graphics driver, etc.
A console running in a Gnome or KDE GUI session is very complicated. The kernel isn't involved in drawing it at all and doesn't know how.
The more complex the output process is, the less likely that a kernel that is already crashing can manage it successfully.
Serial port output is once again very simple. A buffered UART makes it a bit more complicated, but if a crashing kernel wants to ignore that and simply output bytes at a 9,600 line rate, any serial port will work with that without needing buffers or interrupt management.
I am attempting to put a particular device into suspended mode, and have been unable to find a way to do this.
I see in the kernel that a suspend command can be defined, but what is the user space analog to it, if there is one?
In this case, it is to allow me to mask an interrupt in a touchscreen controller before its power is removed.
edited to add additional info:
Additional information: This is for an embedded device, using linux kernel 2.6
the typical sequence is to send a command to the device to put it into 'suspend' mode, then close the open file descriptor to that device.
I'm working with a USB device in Linux and have written a library to control this device.
Without going in to TOO many details, the device uses a standard UART protocol, so all I have to do is open a serial connection with open, configure the relevant parameters like baud rate, stop bit, parity, etc, etc, and start bit-banging registers.
The library works fine, however, it its hard coded to assume that this device is /dev/ttyUSB0. That is, this is what I pass to open. If open fails, I exit.
What I would like to do is detect that this device is present, regardless if it's /dev/ttyUSB0, /dev/ttyUSB1, etc. And even detect if there are multiple of these devices connected.
I can write code to poll certain registers on the device that will return serial number, product ID, etc, so I can detect that what is on the other end of the USB is indeed my device... but how can I find a list of connected USB devices, again, in native C?
OR is there a more elegant way of doing this, such as interfacing with it's kernel module, or something? I can provide the USB driver it actually uses, but I'm sort of lost when looking through the code.
Thanks for any insight.
The elegant method is to use udev to create a descriptive symlink for your device when it is connected. Add a line something like this to /etc/udev/rules.d
SUBSYSTEM=="tty",ENV{ID_MODEL}=="My_FlowMeter_Model",ENV{ID_USB_INTERFACE_NUM}=="00",SYMLINK+="flowmeter",RUN+="/bin/su pi -c /home/pi/record-flowmeter.sh
That's a very slightly modified version of an actual udev rule my research group uses to collect data from USB devices connected to battery-powered Raspberry Pi boxes. It also runs a script automatically, which has commands like
stty -F /dev/flowmeter 500000 -ixon -echo -icanon
If you want to know the "real" device filename, you could do readlink /dev/flowmeter. But for most uses you can just use the link: fd = open("/dev/flowmeter"); (or pass it as an argument to your program)
Naturally you should replace flowmeter with a short name for your own device, as well as updating the ID_MODEL based on the output from lsusb.
Multiple devices are a bit more complicated, but there are plenty of examples of udev rules out there.
On Linux, the information you are looking for is in the /sys filesystem, specifically under /sys/bus/usb/devices. From there you will need to search the filesystem to find your device.
For example, I just plugged a USB-serial dongle into my Linux (kernel version 2.6.35) and the device appeared under /sys/bus/usb/devices/2.1-8. Here, I am able to find that this is my device by vendorId:deviceId by checking the files idVendor and idProduct. Here, there is a directory named 2.1-8:1:0 which contains a directory named ttyUSB0.
Obviously, to find your device you will need code (or a shell script using find) to scan the directory tree, looking for the right entries.
I am developing an application for linux based embedded system which directly writes on the framebuffer device of the Linux kernel.The writing works perfectly. But the problem happens when some other event occurs with a demand of display(Like plugging a flash drive or a kernel message). Every time when it happens, the screen gets interrupted and the unwanted things appear on the screen erasing the previous graphics from the overlapped portion(other things remain unchanged).
How can I get rid of this problem?
Add console=0 to the kernel command line. It disables both the kernel outputting anything to the console, and the console login. (For development purposes, I recommend having a separate boot option, so you can boot to a console.)
Alternatively, have your application create a new virtual terminal for the framebuffer, like X does. This avoids the kernel (kernel console, really) scribbling text all over your framebuffer.