I have an embedded computer system running Linux. Its SoC is an Intel E3845. I was able to find the datasheet.
If the power blinks, the device just reboots. What I want to detect is if the system experienced a power failure that caused it to reboot. There exists on page 4325 this register documentation
This appears to a register of a PCI device. Of interest is bit 16. The documentation seems to indicate this bit is set whenever the machine is running (S0 state) and the system power goes too low.
Running lspci indicates that the system management bus is at this address, along with a power control unit
00:1f.0 ISA bridge: Intel Corporation Atom Processor Z36xxx/Z37xxx Series Power Control Unit (rev 11)
00:1f.3 SMBus: Intel Corporation Atom Processor E3800 Series SMBus Controller (rev 11)
So I think I need to read one of these registers from /sys/bus/pci/devices.
# ls -l /sys/bus/pci/devices/0000\:00\:1f.0/resource*
-r--r--r-- 1 root root 4096 Nov 8 22:53 /sys/bus/pci/devices/0000:00:1f.0/resource
# ls -l /sys/bus/pci/devices/0000\:00\:1f.3/resource*
-r--r--r-- 1 root root 4096 Nov 8 22:53 /sys/bus/pci/devices/0000:00:1f.3/resource
-rw------- 1 root root 32 Nov 8 22:53 /sys/bus/pci/devices/0000:00:1f.3/resource0
-rw------- 1 root root 32 Nov 8 22:53 /sys/bus/pci/devices/0000:00:1f.3/resource4
Actually memory mapping one of these files & reading it should be simple. My questions are
Am I looking in the right place in /sys?
Which file do I need to read? The documentation is indicates an offset of [PMC_BASE_ADDRESS + 20h]. So do I read offset 32 bytes into one of these files?
Can I be sure that the boot loader or some other device is not clearing this bit by writing a 1 into this register? Is that a normal practice?
Related
I was wondering if anyone knows why chromium based browsers trigger direct rendering manager on startup on Linux whereas Firefox for example doesn't seem to do that? This is what I see when starting chromium:
Dec 19 11:02:30 hp kernel: [drm] PCIE GART of 256M enabled (table at 0x000000F400000000).
Dec 19 11:02:31 hp kernel: [drm] UVD and UVD ENC initialized successfully.
Dec 19 11:02:31 hp kernel: [drm] VCE initialized successfully.
I bought a RFlink Gateway from Nodo-shop.nl, the the RFLink 433.42 Somfy RTS version, to use with Domoticz on a RPI. I had Nodo to solder the components of my Rflink, so there should not be any problem on this end :)
I connected it to my MacbookAir, and followed the instructions on Domoticz wiki to upload the firmware into the RFlink. It apparently uploaded the firmware successfully.
Then I updated and upgraded my RPI (Linux raspberrypi 5.4.79-v7+ #1373 SMP Mon Nov 23 13:22:33 GMT 2020 armv7l GNU/Linux) and hooked it up to my Raspberry Pi 3 .
I tried to identify the port with Dmesg. If the Arduino Mega is detected, I cannot see the ttyAMCO or ttyUSB everyone is referring to in various posts.
Here is the output of the dmesg command:
[3902580.423329] usb 1-1.1.2: new full-speed USB device number 9 using dwc_otg [3902580.568650] usb 1-1.1.2: New USB device found, idVendor=2341, idProduct=0042, bcdDevice= 0.01 [3902580.568671] usb 1-1.1.2: New USB device strings: Mfr=1, Product=2, SerialNumber=220 [3902580.568685] usb 1-1.1.2: Manufacturer: Arduino (www.arduino.cc) [3902580.568699] usb 1-1.1.2: SerialNumber: 55037313237351714260
I also tried to look for the port using this command ls /dev | grep tty*. I can only see these ports : ttyXX, ttyAMA0 and ttyprintk. But no sign of the port of my RFlink Gateway.
When I use this command lsusb, it shows it recognizes the Arduino:
Bus 001 Device 009: ID 2341:0042 Arduino SA Mega 2560 R3 (CDC ACM).
I read tons of posts on the internet but I did not find any answer to my problem.
I even bought a power supply for my Arduino Mega as some wrote that it may not get enough power from the RPI's USB. But I still have the same problem...
What I'm not doing right ? Or what am I not looking at ?
Thank you for your help
Sorry, bit late but it might be useful to someone else...
It might well be the /dev/ttyAMA0 you found - it depends what else you've got on there.
listing by id should identify it definitively though:
$ ls -l /dev/serial/by-id/
total 0
lrwxrwxrwx 1 root root 13 Mar 18 2021 usb-0658_0200_12345678-9012-3456-7890-123456789012-if00 -> ../../ttyACM1
lrwxrwxrwx 1 root root 13 Mar 18 2021 usb-Arduino__www.arduino.cc__0042_55639313533351509150-if00 -> ../../ttyACM0
So, in my case it's on /dev/ttyACM0.
If you've got multiple USB serial adapters, reboot the pi with them all plugged in to get the default mapping (I've seen hotplugged AMA0 and AMA1 swap after a reboot).
I'm using the current version of mbpfan (mbpfan-git-2.2.1.r4.g52d8973-1-x86_64) from Arch User Repository, running Arch linux on a MacBookPro 6,1 mid-2010 (on external usb, actually). Mbpfan is a small daemon designed to control mac fan speed and solve heat problems.
After a recent upgrade to 5.8.1 kernal, from 5.7.12, mbpfan does not work,
with error
Aug 20 17:19:56 ehost kernel: applesmc: send_byte(0x03, 0x0300) fail:
0x00 Aug 20 17:19:56 ehost kernel: applesmc: FS! : write data fail
and
ehost mbpfan[380]: Could not set fan speed: Input/output error Aug 20
17:21:56 ehost kernel: applesmc: send_byte(0x40, 0x0300) fail: 0x00
Aug 20 17:21:56 ehost kernel: applesmc: F0Tg: write data fail
FS! fail is saying, can't change fan to "manual," and F0Tg is the first fan where it
tries to write a new speed.
From looking in /sys/devices/platform/applesmc.768 one can see that even root can only write to fan1_manual, fan1_min, and
fan1_output, for example.
-r--r--r-- 1 root root 4096 Aug 18 21:00 fan1_input
-r--r--r-- 1 root root 4096 Aug 18 21:01 fan1_label
-rw-r--r-- 1 root root 4096 Aug 18 21:00 fan1_manual
-r--r--r-- 1 root root 4096 Aug 18 21:00 fan1_max
-rw-r--r-- 1 root root 4096 Aug 18 21:00 fan1_min
-rw-r--r-- 1 root root 4096 Aug 18 21:00 fan1_output
The above permissions have not changed from earlier kernels when mbpfan worked.
They are exactly the same on the installations where mbpfan works (different usb stick, same machine).
Permissions should not be an issue, as I understand that one writes to "fan1_output," which is rw, to set the desired fan speed (counterintuitively).
As a test, I upgraded another installation with a working mbpfan (kernel 5.7.9) to 5.8.1, and the same no write problem appears.
--It seems that something in the kernel that affects mbpfan has changed between
5.7.12 and 5.8.1.
Naturally, I have reported this at the developer's git hub area. I've been digging around in the code a bit, but it's tough going so far as I really know nothing about drivers. --I'd really appreciate any suggestions on what I might try to get this working...
I'm attempted to use a pwm output pin as a IR transmitter using a RAMIPS SoC and the PWM IR TX kernel module. I'm running linux 4.14.37 and have added the following entry to the dts file:
pwm_ir_tx1: pwm-ir-transmitter1 {
compatible = "pwm-ir-tx";
pwms = <&pwm 1 100>;
};
I'm loading the rc-core and pwm-ir-tx kernel modules:
lsmod | grep pwm
pwm_ir_tx 2032 0
pwm_mediatek_ramips 1744 1
rc_core 19348 2 pwm_ir_tx
When the pwm-ir-tx module loads, the kernel logs:
[ 3754.108259] rc rc0: PWM IR Transmitter as /devices/platform/pwm-ir-transmitter1/rc/rc0
The sysfs nodes appear to be loaded correctly:
ls -la /sys/class/rc/
drwxr-xr-x 2 root root 0 May 29 00:18 .
drwxr-xr-x 23 root root 0 Jan 1 1970 ..
lrwxrwxrwx 1 root root 0 May 29 01:16 rc0 -> ../../devices/platform/pwm-ir-transmitter1/rc/rc0
But there is no userspace (chardev) lirc device listed in /dev so I'm not sure how I'm supposed to interact with the device. Ideally I'd like to use the Remote Controller API but this requires a chardev to be present in /dev.
ls /dev
autofs mtd2ro network_throughput
console mtd3 null
cpu_dma_latency mtd3ro port
full mtd4 ptmx
gpiochip0 mtd4ro pts
gpiochip1 mtd5 random
gpiochip2 mtd5ro shm
gpiochip3 mtd6 tty
i2c-0 mtd6ro ttyS0
kmsg mtdblock0 ttyS1
log mtdblock1 ttyS2
memory_bandwidth mtdblock2 urandom
mtd0 mtdblock3 watchdog
mtd0ro mtdblock4 watchdog0
mtd1 mtdblock5 zero
mtd1ro mtdblock6
mtd2 network_latency
I've tried loading the lirc_dev module before and after the pwm-ir-tx module, but nothing appears in /dev still, the following output appears when I load the lirc_dev module:
[ 4775.367966] lirc_dev: IR Remote Control driver registered, major 251
But still no lirc userspace device in /dev... I'm thinking the lirc_dev module is required since it provides the lirc userspace api but there doesn't appear to be any connection between it and the pwm-ir-tx module, and it's not creating any lirc chardevs in /dev.
The pwm_ir_tx module seems to be more or less a piggy-back to the pwm driver. And the pwm driver seems to be available at /sys/class/pwm/. See https://www.kernel.org/doc/Documentation/pwm.txt.
BTW, not having a lirc link in rc0/ is not uncommon - not all drivers implements this.
After reading some of rc source files in the kernel, it became obvious the ir-lirc-codec module was also required.
Basically, the pwm-ir-tx driver is defined as a type of RC_DRIVER_IR_RAW_TX. When the rc-core module registers a driver with a type of RC_DRIVER_IR_RAW or RC_DRIVER_IR_RAW_TX it calls the ir_raw_event_prepare function which in turn tries to load the ir-lirc-codec module. Once this module was available the following kernel logs appear:
[ 10.004460] lirc_dev: IR Remote Control driver registered, major 251
[ 10.131011] IR LIRC bridge handler initialized
[ 10.471561] rc rc0: PWM IR Transmitter as /devices/platform/pwm-ir-transmitter1/rc/rc0
[ 10.487456] rc rc0: lirc_dev: driver ir-lirc-codec (pwm-ir-tx) registered at minor = 0
And in /dev there is a lirc chardev device available:
ls /dev/li*
/dev/lirc0
I have an application that I eventually want to run on a cloud computing service (e.g., such as AWS or Google Cloud) packaged inside a docker image. The reason the application will need to run in the cloud is because it's designed to process large data files, but before I actually deploy, I'd like to test it first on a local laptop, using a single large data file that I've stored (for test and development purposes) on an external USB drive.
My development machine is an OSX laptop, and I'm using a recent version of docker:
stachyra> uname -a
Darwin Andrews-MacBook-Pro-76.local 14.5.0 Darwin Kernel Version 14.5.0: Tue Sep 1 21:23:09 PDT 2015; root:xnu-2782.50.1~1/RELEASE_X86_64 x86_64
stachyra> docker --version
Docker version 1.10.2, build c3959b1
OSX has mounted my external USB drive, device /dev/disk2s2, as /Volumes/MGR DATA:
stachyra> df
Filesystem 512-blocks Used Available Capacity iused ifree %iused Mounted on
/dev/disk1 974770480 435721376 538537104 45% 54529170 67317138 45% /
devfs 375 375 0 100% 650 0 100% /dev
map -hosts 0 0 0 100% 0 0 100% /net
map auto_home 0 0 0 100% 0 0 100% /home
/dev/disk2s2 3906291632 3869523640 36767992 100% 483690453 4595999 99% /Volumes/MGR DATA
/dev/disk3s1 196608 193160 3448 99% 24143 431 98% /Volumes/VirtualBox
stachyra> diskutil list
/dev/disk0
#: TYPE NAME SIZE IDENTIFIER
0: GUID_partition_scheme *500.3 GB disk0
1: EFI EFI 209.7 MB disk0s1
2: Apple_CoreStorage 499.4 GB disk0s2
3: Apple_Boot Recovery HD 650.0 MB disk0s3
/dev/disk1
#: TYPE NAME SIZE IDENTIFIER
0: Apple_HFS Macintosh HD *499.1 GB disk1
Logical Volume on disk0s2
DB70B91A-3B57-4C82-A758-C4BDEA4160FD
Unlocked Encrypted
/dev/disk2
#: TYPE NAME SIZE IDENTIFIER
0: GUID_partition_scheme *2.0 TB disk2
1: EFI EFI 209.7 MB disk2s1
2: Apple_HFS MGR DATA 2.0 TB disk2s2
/dev/disk3
#: TYPE NAME SIZE IDENTIFIER
0: GUID_partition_scheme *100.7 MB disk3
1: Apple_HFS VirtualBox 100.7 MB disk3s1
and it should also be noted, the drive has several directories and data which are visible inside it, at least when viewed directly through OSX:
stachyra> ls -l /Volumes/MGR\ DATA
total 0
drwxr-xr-x 6 stachyra staff 204 Apr 14 2015 1000genomes
drwxr-xr-x 5 stachyra staff 170 Oct 12 17:41 GIAB
drwxr-xr-x 4 stachyra staff 136 Apr 28 2015 genome_browser_tracks
drwxr-xr-x 24 stachyra staff 816 Oct 6 14:00 mitty
I have tried to follow the advice from this question, which describes how to mount a USB drive in docker when docker is running within a linux host. But my local laptop is OSX, not linux, so it doesn't seem to work.
Explicitly, when attempting to follow the advice of the accepted answer, I obtain the following result:
stachyra> docker run -i -t --privileged -v /dev/disk2s2:/dev/foo ubuntu bash
root#8da7b492a707:/# uname -a
Linux 8da7b492a707 4.1.18-boot2docker #1 SMP Sat Feb 20 08:24:27 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux
root#8da7b492a707:/# ls -l /dev/foo
total 0
root#8da7b492a707:/#
Based upon the response, one can see that docker does indeed launch a linux container correctly, and it also creates a volume /dev/foo inside of the container as requested, but the actual contents of the USB drive are not accessible via that location--the ls -l command claims there are no files or directories there.
I also tried the second method described in an alternate response to the same question, and that fails even worse:
stachyra> docker run -i -t --device=/dev/disk2s2 ubuntu bash
docker: Error response from daemon: error gathering device information while adding custom device "/dev/disk2s2": not a device node.
stachyra>
I have found another discussion thread on stackoverflow which suggests that raw USB access is handled quite differently in OSX than in linux, which I suspect is probably the reason why both of the above attempts at USB access are failing.
But, what should I actually do about it? That is to say, what is the correct sequence of actions or commands to allow docker to access a USB device mounted on an OSX host, rather than linux?
I was finally able to access my USB drive from /var/media inside my container by using the machine-diskutil.sh script mentioned in warmoverflow's comment like so
machine-diskutil.sh mount my-machine-name /Volumes/my-usb-drive
and then starting the container like so
docker run -v /Volumes/my-usb-drive:/var/media -it my/image:latest bash
Because I had tried to add /Volumes/my-usb-drive as a shared folder manually in VirtualBox, I first got this error.
Error: The shared folder /Volumes/Seagate already exists on the
docker machine, please unmount it first.
So I removed it manually and re-ran the machine-diskutil.sh mount command without any problems. Great stuff!
As per #pgayvallet comment on GitHub:
As the daemon runs inside a VM in Docker Desktop, it is not possible to actually share a mac host device with the container inside the VM, and this will most definitely never be possible.