Currently trying to implement a net-booted RPi3b+ network and there is an auxiliary board to these pi's I've had printed. The auxiliary board has a classic DS18B20 among other things to monitor the temperature of the box the rpi and aux board are contained in.
The issue is, when I use a netbooted pi I cannot get any devices to show up (including the w1_bus_master1) when I access /sys/bus/w1/devices. See below,
pi#raspberrypi:/etc $ cd /sys/bus/w1/devices/
pi#raspberrypi:/sys/bus/w1/devices $ ls -l
total 0
I know that my circuit is correct as it works when I boot the RPi from an SD card with the same image of raspbian as the netbooted image. On the netbooted rpi I see the 1-wire processes running for w1-therm and w1-gpio.
lsmod
Module Size Used by
w1_therm 16384 0
w1_gpio 16384 0
wire 40960 2 w1_gpio,w1_therm
My netbooting process roughly follows this tutorial,
https://blockdev.io/network-booting-a-raspberry-pi-3/
I have a NFS mount which holds the config.txt file containing the
dtoverlay=w1-gpio,gpiopin=4
I'm pulling my hair out a bit here, really would like to maintain the netbooting capability as this implementation is preferred to last and is across 30+ pi's, don't want to be pissing about the sd cards.
Cheers
Related
What goes behind the hood when i add a new NIC card to my Ubuntu machine.?
Which program/module is responsible for mapping the HardWare address of the device to a name(eth0/eth1). Where are this mappings(HWaddress1-eth0, HWaddress2-eth1) actually stored.?
As far as I know the kernel itself will name the nics depending on the order they are connected to the bus. This behavior is very similar to SCSI/SATA naming.
Take a look at the output of
lspci
You should find the corresponding network card there. The first column e.g. 0000:00:03.0 contains the following information:
0000 : PCI domain (each domain can contain up to 256 PCI buses)
00 : the bus number the device is attached to
03 : the device number
.0 : PCI device function
(source: http://prefetch.net/articles/linuxpci.html)
under /sys/bus/pci(_express)/devices/ you will find links that match to the lspci output. When you enter the folder of your network card, there are lots of files and folders.
You can do a find and grep
cd /sys/bus/.../devices/0000:00:03.0/
someuser#somemachine:/sys/bus/pci/devices/0000:00:03.0$ find -type f -exec grep 'ethX' /dev/null {} \; 2>/dev/null
where ethX is your device name to get an output like
./virtio0/net/ethX/uevent:INTERFACE=eth0
(in my case a virtual machine with a virtio device)
Since this information is derived from the running kernel I bet you will also find the hardware-address there.
Happy grepping!
I want to use my BeagleBone Black to setup a Webcam. I installed fswebcam and configured it to take a picture every 10 seconds. However, the BeagleBone produces the following errors in dmesg every few minutes:
dmesg | tail -n 3
-> [ 220.258214] musb_host_rx 1762: Rx interrupt with no errors or packet!
-> [ 490.302277] musb_ep_program 896: broken !rx_reinit, ep13 csr 0003
-> [ 490.308731] musb_host_rx 1762: Rx interrupt with no errors or packet!
After a few hours (at most!) it freezes up completely and I have to power-cycle it. (The power-button doesn't shut it down anymore.)
This error has been bugging me for weeks. I tried all possible configurations I can think of:
Three different Beaglebones: Two revision A5A and one revision A5C
Five different Power supplies: Three via USB, two via Barrel connector
Three different Webcams: One Logitech C920, one HP 3100, one no-name El-Cheapo
Two different Linux distributions: The current ArmHF Ubuntu 14.04 distribution and the currently linked debian distribution on the official "latest images" page (which is a few months behind!). I updated the Kernel of the latter image using the appropriate script in /opt/scripts - but that did not help either.
I installed fswebcam through package managers and compiled it from source.
For fswebcam I tried various config files (including delays and skipping images). One example config file that I tried:
background
loop 10
resolution 1920x1080
scale 1280x720
title "test-picture"
timestamp "%d.%m.%Y %H:%M:%S (%Z)"
jpeg 70
banner-colour #FF000000
line-colour #FF000000
no-shadow
save ~/test-picture.jpg
How can I keep my BeagleBone Black from crashing?
Update: I finally got it to work using a (borrowed) Rev A5C BeagleBone. I still get the dmesg errors, but at least the BeagleBone does not crash. I currently suspect a hardware issue on the RevA5B BeagleBone.
The primary video card usually can be set in the BIOS (option Primary VGA card), and it will be the first card used by the system.
My question is how can I programmatically identify (using a shell script and utilities is preferable) which of my two video cards is the primary card?
Edit: I was hoping that I wouldn't have to elaborate why I need this, because it is a bit complex, but I will explain the problem below.
I have a configuration wizard which allows the dynamic configuration of a multiseat system in a LiveCD, with two independent displays, keyboards and mice, my wizard works in this way:
Start one Xorg server per video card (after generating xorg.conf with the correct PCI bus ID).
Start a ui in each of Xorgs with messages for configuration (press key and press mouse). One seat can be configured each time.
After the first seat is configured, the wizard closes the first Xorg and start the definitive Xorg in this seat with the desktop environment (already with the correct keyboard and mouse set).
The second seat now is able to be configured (press key and mouse), after this pass 3 is repeated for seat two.
The problem is: If I start the first Xorg in the primary video card, everything works, but if I start the first Xorg in the secondary card this is what happens:
The passes 1, 2, and 3 works, but at the end of pass 3, when the Xorg of the first seat is closed, the Xorg of the second seat blinks and doesn't come back, just show a blank screen with a _ cursor at top, the desktop of the first seat loads, but I don't see the wizard screen in the second seat, the first Xorg just comes back if I execute a kill -HUP , and I need to start the ui from it again.
So, it is why I need to identify the primary video card before I can start Xorg (sorry I didn't mention this before). I tested this system in different computers, with different video cards and the behavior is the same. I also tested with the lasted packages of the kernel and Xorg in Ubuntu 12.04 (packages of the raring release).
Assuming X11 is running, you could suppose that primary card is the one used by Xorg... then you might try
ls -l /proc/$(pidof X)/fd |grep /dev/dri
on my system Debian/Sid/x86-64 with Linux 3.12 kernel (which has an Nvidia card on a Intel3770K which also has its VGA) I'm getting /dev/dri/card0 etc...
But you should explain really why you are asking and what problem do you want to solve.... Why does that matter to you?
I am not at all sure that Linux has a notion of primary graphic card like the BIOS knows it.
And probably hwinfo is telling you everything about your graphical cards.
There are several command line tools in Linux that give you human readable information from the BIOS. Maybe you can find your Video boards in there and see which one is made primary. From what I see in my output, it does not look like something says "this is the primary video", but I do see quite a lot of information. You could output that information to a file when video card A is primary, again when B is primary, then compare those two files and see whether there is a difference.
The command I used, which gives me a lot of information, is dmidecode:
sudo dmidecode | less
If you look at the manual page:
man dmidecode
You will notice that the programmers offer a few other similar tools such as biosdecode and vpddecode.
From those you learn that the BIOS information is available from the /dev/mem device. Although you need to be root to read it, if you know the address (I don't) then you could go in there and peek and poke as required to find out where that one information of which video card is defined as the primary video card.
Running dmidecode, there are some details about my motherboard:
Handle 0x0002, DMI type 2, 15 bytes
Base Board Information
Manufacturer: Supermicro
Product Name: X9SCI/X9SCA
Version: 1.01
Serial Number: ZM25U44192
Asset Tag: To be filled by O.E.M.
Features:
Board is a hosting board
Board is replaceable
Location In Chassis: To be filled by O.E.M.
Chassis Handle: 0x0003
Type: Motherboard
Contained Object Handles: 0
Here I have one video entry:
Handle 0x000E, DMI type 10, 6 bytes
On Board Device Information
Type: Video
Status: Enabled
Description: To Be Filled By O.E.M.
Then the other entry looks like this:
Handle 0x0036, DMI type 41, 11 bytes
Onboard Device
Reference Designation: Onboard IGD
Type: Video
Status: Enabled
Type Instance: 1
Bus Address: 0000:00:02.0
It could also be something you need to read from the Flash memory your BIOS uses. This is done with flashrom (that you may need to install):
sudo flashrom --programmer internal --read my-flash.bin
In my case the ROM on my computer is 2Gb of data. So quite large. However, you can be sure that the information you are looking for exists within that data block since that is the only mean for the BIOS to save data that will stay around when the computer gets turned off.
I have found a way how to check the primary GPU when they are from different vendors or at least have different names.
In KDE go to Info Center, then open Graphics -> OpenGL. In Direct Rendering (GLX) and Direct Rendering (EGL) you can see a Driver block. You can see the Vendor and Device there. It will name the GPU which is primary.
At this screenshot you can see that AMD gpu is primary:
Also, you can get that Vendor value programmatically by running
glxinfo | grep "OpenGL vendor string" | cut -f2 -d":" | xargs.
I guess this method will stop working when kde will switch to vulkan for rendering (in kde 6). But for now I do not know another method of determining primary gpu.
After having set-up and customized my "master" BeagleBone Black (BBB) with applications etc. on the on-board eMMC, I want to duplicate it on other BBB boards.
What is the best way to duplicate the BBB?
My understanding of options:
SD-Card: Programming each board by inserting a prepared SD card containing an image and pressing the "boot" switch while powering up.
How should I prepare that .img file or the SD card from my master BBB?
The image should copy to the on-board eMMC, so that the SD-card can be removed afterwards.
USB: Programming by connecting the board over USB to a (Win7) PC.
Is it possible to write the full on-board eMMC from the PC?
With which app to do the writing?
How to prepare the image which will be written, starting from the master BBB?
Ethernet: Programming over LAN after boot-up with default angstrom distro.
Is it even possible over LAN?
How to do the writing?
How to prepare the image which will be written, starting from the master BBB?
Which is possible/best?
Edit: My current solution is to flash with a standard image (from the BeagleBoe website) and then have a script do all modifications as expected. This includes disabling many services I don't need, installing applications and configuring stuff etc.
If there is an easier way for making a SD card with a full image on it, I'm still interested.
As noted at the bottom of the eLinux article, there is a much easier way if you are running the Debian distribution:
Boot master BBB with no SD card in
Insert SD card
Log in (e.g. with serial terminal, SSH etc.) and run sudo /opt/scripts/tools/eMMC/beaglebone-black-make-microSD-flasher-from-eMMC.sh. LEDs will flash in sequence whilst SD card is being written.
When the LEDs stop and the script terminates, remove the SD card.
Insert SD card into new BBB then power on.
eMMC will be flashed; LEDs on new BBB will flash in sequence until complete.
For anyone else that needs this, the best answer I've found to this is to do the following:
First setup your master Beaglebone Black the way you want it.
Backup the eMMC
FAT format a 4GB or larger SD card (must be a MBR/bootable formatted microSD card)
Download beagleboneblack-save-emmc.zip and extract the contents onto your SD card
Note: this is an image from Jason Krinder at his github https://github.com/jadonk/buildroot using the save-emmc-0.0.1 tag
Put the card into your powered off Beaglebone Black
Power on your Beaglebone Black while holding the S2 Button
The USR0 led will blink for about 10 minutes, when it's steady on you have an SD card with a copy of your eMMC in a .img file
Use the eMMC to flash a new Beaglebone Black
On the SD card edit autorun.sh
#!/bin/sh
echo timer > /sys/class/leds/beaglebone\:green\:usr0/trigger
dd if=/mnt/<image-file>.img of=/dev/mmcblk1 bs=10M
sync
echo default-on > /sys/class/leds/beaglebone\:green\:usr0/trigger
where <image-file> is the image file you got after copying backing up your eMMC
Insert the card into your powered off Beaglebone Black
Power on your Beaglebone Black while holding the S2 Button
The Beaglebone Black should go into rebuilding mode and within about 20 minutes you'll have a newly flashed Beaglebone Black (when all 4 USR LEDs are solid) with a copy of your original
eLinux reference used for this article - http://elinux.org/BeagleBone_Black_Extracting_eMMC_contents
I have the same need and am using dd and nc (NetCat) to save directly on my desktop without having to use an intermediary SD Card. You can do this over the USB connection, or ethernet connection, by changing the IP address in the steps below.
After setting up your BBB with the applications you want, the basic steps are:
On the desktop, run this command in a terminal:
nc -l 19000|bzip2 -d|dd bs=16M of=BBB.img
On the BeagleBone Black, run this command in a terminal (you can SSH into it, or do it directly from the BBB):
dd bs=16M if=/dev/mmcblk0|bzip2 -c|nc 192.168.7.1 19000
The 192.168.7.1 address is for the USB connection. (BBB is 192.168.7.2) If you're doing this over an ethernet connection, you should use your desktop's IP address.
This is taken from instructions here.
Finally, follow any method to install onto the next BBB. Here's an example of how to flash the emmc.
Copying your emmc Image back to a SD card is a bit tricky, since it will need to be formated in a certain way to get it to mount. Here are some tips to get that working: http://dev.gentoo.org/~armin76/arm/beagleboneblack/install_emmc.xml#expand
What might be easier is using an USB thumb drive, or USB SD card reader. Note, currently there are some issues hot-plugging USB devices, so boot with it plugged in.
You can copy your entire FS to the USB drive, then compress it. Create a new bootable linux sd image, and put your compressed FS on there and use one of the scripts Ottavio linked to to copy over the compressed image. you can make a systemd service to launch the script on startup.
We have noticed that on Beaglebones with the Jan 23rd 2015 release of Debian, the only way to successfully copy the image from SD is not to hold the boot button down when powering up.
Trying to get access to a partially rooted Galaxy S2 external sd card.
The problem is that /dev/block/mmcblk1p1 does not exist on the phone. This is the device name that should allow me to put the "recovery" image onto the sdcard so that the unit will be a phone again.
Problem is, I don't know where to find the magic Major and Minor numbers for this device and I'm trying to figure out where in the kernel source I should be looking for them.
Could someone point me at the right kernel files to find this information?
Standard devices use predefined major numbers and minor numbers starting from 0 for the first instance and upward depending on how many instances there are going to be.
Look at the Linux Documentation file(devices.txt) to see the full list but the section of interest to you is:
179 block MMC block devices
0 = /dev/mmcblk0 First SD/MMC card
1 = /dev/mmcblk0p1 First partition on first MMC card
8 = /dev/mmcblk1 Second SD/MMC card
...
The start of next SD/MMC card can be configured with
CONFIG_MMC_BLOCK_MINORS, or overridden at boot/modprobe
time using the mmcblk.perdev_minors option. That would
bump the offset between each card to be the configured
value instead of the default 8.
So /dev/block/mmcblk1p1 would be major 179, minor 9.
According to hotplug.txt
Entries for block devices are found at the following locations:
/sys/block/*/dev
/sys/block/*/*/dev
So try looking in /sys/block/mmcblk1p1/dev.
EDIT:
Looking at it again I actually think that it will be in /sys/block/mmcblk1/mmcblk1p1/dev