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
Related
I am using linux 20.04 to build an image for the IMX8QXP, the image is based on kernel SUMO 4.14.98.
I am using one of the SIMCOM7600E.
I starts to dial up via NIC by using below command :
AT+CREG = 1
+CREG=1,1
return OK
AT+CGREG = 1
+CGREG=1,1
return OK
AT$QCRMCALL=1,1
return No CARRIER
I cant seem to fix the problem or figure out what is wrong. Please help me trouble shoot the problem!!
My guess would be:
The module can be registered in network, but the selected network mode may be unsuitable for data transmission (e.g. voice calls only or other). Check the preferred mode by using AT+CNMP?. The return value of 2 indicates auto.
Make sure that you have data plan available. Also remove PIN lock on the SIM card
Check if the signal quality is decent: try AT+CSQ. Its return value will be in format ,. RSSI stands for Received Signal Strength Indicator and BER for Bit Error Rate. RSSI value ranges can be in between 0 (minimum, =< -113dBm) to 31 (maximum, >= -51 dBm).
Look for more information about the operator: AT+COPS? and the network mode: AT+CPSI?
Based on the information obtained in previous steps, use an appropriate antenna or adjust its location if necessary
Don't forget about the stable power supply
If you didn't have much success with AT$QCRMCALL=1,1, try changing the USB PID of the module to 9011 (for using the modules as a RNDIS modem): AT+CUSBPIDSWITCH=9011,1,1 (the default PID is 9001)
I would flash a new firmware only as a last resort. Usually this is not necessary
Reference:
SIM7600 AT Commands manual v3.0
I made an app that discovers Bluetooth devices around me, and I'm looking into the datas I get about them. Now I'm trying to figure out the datas from BluetoothDevice.getBluetoothClass (CoD, Class of Device).
So far I've found these class codes around me:
43c
50c
704
1f00
c043c
c243c
8043c
60680
200408
240414
5a020c
About half of these I found some information for (http://domoticx.com/bluetooth-class-of-device-lijst-cod/). The rest of the codes I haven't been able to find anywhere (50c, c043c, c243c, 60680).
Does anyone know any overview with all of these codes (or at least the ones I haven't figured out)?
You can decode the Bluetooth Class of Device (CoD) yourself by first converting the above hex number to binary (for example using this link) and then checking the document below to try and find what the combination of the bits mean:-
https://www.ampedrftech.com/datasheets/cod_definition.pdf
As an example, 0x50c is 010100001100 in binary. Using the table in the document above, bits 8 to 12 indicate that the device is a peripheral:
And then bits 2 to 5 indicate that the device is a remote control
in the book 2017 " UNIX and Linux System Administration " i've read the article below :
Modern systems manage their device files automatically. However, a few rare corner
cases may still require you to create devices manually with the mknod command.
So here’s how to do it:
mknod filename type major minor
Here, filename is the device file to be created, type is c for a character device or b
for a block device, and major and minor are the major and minor device numbers.
If you are creating a device file that refers to a driver that’s already present in your
kernel, check the documentation for the driver to find the appropriate major and
minor device numbers.
where can i find this doc and how to find Major & Minor for a device driver ???
The command cat /proc/devices shows the character and block major device numbers in use by drivers in the currently running Linux kernel, but provides no information about minor device numbers.
There is a list of pre-assigned (reserved) device numbers in the Linux kernel user's and administrator's guide: Linux allocated devices (4.x+ version). (The same list also appears in "Documentation/admin-guide/devices.txt" in the Linux kernel sources.) The list shows how minor device numbers are interpreted for each pre-assigned character and block major device number.
Some major device numbers are reserved for local or experimental use, or for dynamic assignment:
60-63 char LOCAL/EXPERIMENTAL USE
60-63 block LOCAL/EXPERIMENTAL USE
Allocated for local/experimental use. For devices not
assigned official numbers, these ranges should be
used in order to avoid conflicting with future assignments.
120-127 char LOCAL/EXPERIMENTAL USE
120-127 block LOCAL/EXPERIMENTAL USE
Allocated for local/experimental use. For devices not
assigned official numbers, these ranges should be
used in order to avoid conflicting with future assignments.
234-254 char RESERVED FOR DYNAMIC ASSIGNMENT
Character devices that request a dynamic allocation of major number will
take numbers starting from 254 and downward.
240-254 block LOCAL/EXPERIMENTAL USE
Allocated for local/experimental use. For devices not
assigned official numbers, these ranges should be
used in order to avoid conflicting with future assignments.
384-511 char RESERVED FOR DYNAMIC ASSIGNMENT
Character devices that request a dynamic allocation of major
number will take numbers starting from 511 and downward,
once the 234-254 range is full.
Character device drivers that call alloc_chrdev_region() to register a range of character device numbers will be assigned an unused major device number from the dynamic range. The same is true for character device drivers that call __register_chrdev() with the first argument (major) set to 0.
Some external ("out-of-tree") Linux kernel modules have a module parameter to allow their default major device number to be specified at module load time. That is useful for drivers that do not create their "/dev" entries dynamically, but want some flexibility for the system administrator to choose a major device number when creating device files manually with mknod.
docs:
https://www.oreilly.com/library/view/linux-device-drivers/0596000081/ch03s02.html
https://tldp.org/LDP/tlk/dd/drivers.html
how to find the appropriate minor & major number for a device number:
ls -l /dev/
cat /proc/devices shows the same as lsblk
I'm trying to identify USB keyboards by the physical port it's connected to, including which USB hub.
From experiments I've identified the following:
/devices/platform/soc/3f980000.usb/usb1/1-1/1-1.2/1-1.2.4/1-1.2.4.2/1-1.2.4.2:1.0/0003:0461:0010.0024/input/input49/event4
The first part, /devices/platform/soc/3f980000.usb/usb1/ appears to be constant given a system.
I guess it might be different on another system.
The last part, /input/input49/event4 appears to be increasing every insertion.
Each part starting with /1-1 appears to represent one hub in the USB chain, every later one starting with the full path of the previous one.
The last part in the /1-1 chain contains : which identifies sub components inside that USB device.
However only the second number in :1.0 appears to correlate with interface number, the first one is always 1 and I'm not sure how it could change or what that would mean.
My guess would be to identify the last part not containing : and use that as the physical USB path.
0003 looks like it could be USB class: HID
0461:0010 looks like VID:PID
0024 Increases by every insertion
Are my assumption correct?
Is there a reliable way to identify location in the USB Port tree from either UDev path other means?
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.