I installed funtoo on surface pro 2. All works good except situation when you're booting tablet on battery power. In this case I'm getting error bellow every 20 sec and tablet doesn't react on keypress, touch, doesn't log anything. fsck says there is no errors with disk.
EH complete
exception Emask 0x0 SAct 0x0 SErr 0x50000 action 0x6 frozen
SError: {.PHYRdyChg CommWake }
failed command: WRITE DMA
cmd ca/00:20:f0:0f:c4/00::00:00:00:00:e3 tag 15 dma 16384 out
res 40/00:00:00:00:00:/00:00:00:00:00/00 Emask 0x4 (timeout)
statys: {DRDY}
Kernel: sys-kernel/debian-sources 4.8.15
This looks a power saving issue
If you have TLP try to disable it here /usr/sbin/tlp.
Comment out
# set_sata_link_power $1
More info you can find in following discussion
(I know this is mac related discussion but can be useful for finding a solution for your setup)
Related
I'm working on an embedded linux project using PetaLinux and running on kernel 5.4.0-xilinx-v2020.1. We have multiple apps that needs to write their ~200 bytes config in a file every second for years at a time so we chose to include an 8kB FRAM on the board. The number of apps running isn't fixed, nor is the size of the data each will need to write so a filesystem seems like the easiest, user-friendliest and most transparent solution.
I've found the littlefs-fuse project and I've tested it on my workstation with a 8k loop device, everything is working as expected.
I'm currently in the integration phase and I'm having some issues creating the littlefs filesystem on the FRAM, here's how I'm hoping things would work:
The FRAM is setup in the device-tree as a 24c64-eeprom-compatible i2c device
Linux loads the at24 as expected and create the /sys/bus/i2c/devices/x-xxxx/ folder
I can read and write using bash commands to the /sys/bus/i2c/devices/x-xxxx/eeprom file
I create a loop device using the eeprom file
I use the littlefs-fuse project to create my file system and mount it
I'm currently stuck at the end of part 4, I created a loop device with the eeprom file using losetup -fP /sys/bus/i2c/devices/x-xxxx/eeprom and it works fine without any error but I can't access any data on it.
Here's the error message I get when I try to cat the file
# cat /dev/loop0
cat: read error: Input/output error
And here's what I can find with dmesg concerning the error:
[11950.780699] print_req_error: 5 callbacks suppressed
[11950.780706] blk_update_request: I/O error, dev loop0, sector 0 op 0x0:(READ) flags 0x80700 phys_seg 2 prio class 0
[11950.795985] blk_update_request: I/O error, dev loop0, sector 0 op 0x0:(READ) flags 0x0 phys_seg 1 prio class 0
[11950.805985] buffer_io_error: 3 callbacks suppressed
[11950.805990] Buffer I/O error on dev loop0, logical block 0, async page read
[11950.817854] blk_update_request: I/O error, dev loop0, sector 0 op 0x0:(READ) flags 0x0 phys_seg 1 prio class 0
[11950.827846] Buffer I/O error on dev loop0, logical block 0, async page read
It's completly possible I'm try to fit a square peg in a round hole here but as far as I know, any file is supposed to work with a loop device so I'm confused as to why it's not working as I expect
I have a problem with the i2c/SMBus on a Linux System with an Intel Apollo Lake processor. I am trying to read/write from/to an EEPROM but I face some issues. My EEPROM is located at the address 0x56, and I am able to watch the Bus with my Logic Analyzer.
When I try to read from the device via i2ctools (i2cget) the System behaves as expected. My issue occurs when I try to perform a write command via i2cset for example. i2cset ends with an error (Write failed). Because I am able to watch the Bus electrically I can also say that all lines stay HIGH and the Bus is not touched. I was able to activate the dev_dbg() functions in the i2c driver i2c_i801 and when I perform i2cset I am able to find (dmesg) the debug message:
[ 765.095591] [2753] i2c_i801:i801_check_post:433: i801_smbus 0000:00:1f.1: No response
When running my minimal I²C Python code using the smbus2 lib, I get the following error message and the above mentioned debug message:
from smbus2 import SMBus
bus = SMBus(0)
b = bus.read_byte_data(86,10) #<- This is performed
b = bus.write_byte_data(86,10,12) #<- This is not performed
bus.close()
Error:
File "usr/local/lib/python3.8/dist-packagers/smbus2-0.4.0-py3.8.egg/smbus/smbus2.py", line 455, in write_byte_data
ioctl(self.fd, I2C_SMBUS, msg)
OSERROR: [Errno 6] No such device or adress
A big hint for me is that I am not able to perform a write command in the address space form 0x50 to 0x57. My guess is that some driver locks the address space to prevent write command to that "dangerous" area.
My question is: "Does anyone know this kind of behavior and is there a solution so that I can write to my EEPROM at address 0x56? OR Is there a lock surrounding the i2c adress space from 0x50 to 0x57 and who is my opponent?"
I am kind of a newbie to the whole driver and kernel world so please be kind and it is quite possible that I made a beginner mistake.
I would appreciate hints and tips I can look after surrounding my problem.
It seems that I found the cause of my problem. In this Forum post is described that Intel changed a configuration Bit at the SMBus controller.
OK, I know what's going on.
Starting with the 8-Series/C220 chipsets, Intel introduced a new
configuration bit for the SMBus controller in register HOSTC (PCI
D31:F3 Address Offset 40h):
Bit 4 SPD Write Disable - R/WO.
0 = SPD write enabled.
1 = SPD write disabled. Writes to SMBus addresses 50h - 57h are
disabled.
This badly documented change in the configuration explains the issues.
One Challenge is, that to apply and enable changes to the SPD-write Bit the System needs to be rebooted. Unfortunately while rebooting the BIOS will change the Bit back to the default. The only solution seems to be an adaption in the BIOS.
For me, this issue is resolved. I just wanted to share this information in case someone faces the same issues.
I have problem flashing main program and SoftDevice on the nrf 51822 module. I have Keil version 5.24 and I am using SDK v12.3 .
I can flash SoftDevice easily but after that I can not flash the main program on the device. in the Keil it just shows the error erase failed, flash download failed - "cortex-m0" . But if i try to do this process by the nRFgo studio after that i flashed SoftDevice, when i try to flash the main program it shows the error : This hex file has data in SoftDevice region. Try programming using "Program SoftDevice", or erase all before programming.
Could it be cause because of ROM memory area configuration and addresses? If so how can i fix it?
Thank for your attention.
After a while, I finally found out where the problem was laid.
I tried to change the ROM memory allocation for SoftDevice and main program and it finally works.
Basically SoftDevice allocation must be bellow the main program in the memory. For example if we have memory form 0x00 to 0xff, The SoftDevice can be allocated from 0x00 to 0x2f and the remained area from 0x2f to the end must be reserved for main program.
Depending on which SoftDevice(SD) you use eg. S110, S130 etc. , The size of SDs can vary So the memory allocation of SDs start from 0x00 but the ending point depends on which SD you use, So I changed the memory allocation address in Kiel, And can get information about SDs compatibility with nRF devices and SDs features in the site :
https://infocenter.nordicsemi.com
Here is another helpful link :
https://devzone.nordicsemi.com/f/nordic-q-a/38067/ble_app_uart-can-not-be-loaded-completely-on-nrf-51822
I've faced with the following trouble. I try debugging "vmlinux" kernel (4.4.5 from kernel.org) build for arm7m architecture with debug info on.
I set by hands parameters via r0=0, r1=0, r2=0x8004000. My problem is when it reaches line 108 of "arch/arm/mm/proc-v7m.S" which is "svc #0" PC changes to 0x0 and everything ends.
My board is stm32f429-disc1. Kernel is located in flash starting at 0x8008000. Bootloader initializes clock, USART, SDRAM and calls the kernel.
The code around the fail line is the following :-
107. cpsie i
108. svc #0
109. cpsid i
So I expected the conttroller to jump to SVC ISR instead of changing PC to 0.
I am trying to get an original BeagleBoard (revC4) to boot a Angstrom OpenEmbedded image. Using instructions found here:
http://elinux.org/BeagleBoardAndOpenEmbeddedGit
and:
http://www.angstrom-distribution.org/building-angstrom
I have followed everything but the program freeze with message booting the kernel.
Output:
Texas Instruments X-Loader 1.4.2 (Feb 19 2009 - 12:01:24)
Reading boot sector
Loading u-boot.bin from mmc
U-Boot 2009.11 (Feb 23 2010 - 15:33:48)
OMAP3530-GP ES3.1, CPU-OPP2 L3-165MHz
OMAP3 Beagle board + LPDDR/NAND
I2C: ready
DRAM: 256 MB
NAND: 256 MiB
In: serial
Out: serial
Err: serial
Board revision C4
Die ID #40a8000400000000040365fa1301c014
Hit any key to stop autoboot: 0
mmc1 is available
reading boot.scr
** Unable to read "boot.scr" from mmc 0:1 **
reading uImage
4335440 bytes read
Booting from mmc ...
Booting kernel from Legacy Image at 82000000 ...
Image Name: Linux-3.2.28
Image Type: ARM Linux Kernel Image (uncompressed)
Data Size: 4335376 Bytes = 4.1 MB
Load Address: 80008000
Entry Point: 80008000
Verifying Checksum ... OK
Loading Kernel Image ... OK
OK
Starting kernel ...
Uncompressing Linux... done, booting the kernel.
I have tried both ttyS2 and ttyO2 in the bootargs without difference and have also upgraded both the xLoader and uBoot.
My end goal is to run a rudimentary ROS (Robot Operating System) and the BeagleBoard.
Any help would truly be appreciated.
I don't know if you ever got past this, but as I have recently been trying to get a Beagleboard up and running again, I'll put an answer here for the sake of anyone else trying to get things working.
TLDR version: Use Angstrom v2013.6 and hold the user button as you boot (or zero out the NAND flash) for the easiest solution that just works. See below for more details.
First of all, the place you're stuck at here is due to the u-boot flashed into NAND being out-of-date for a recent version of Angstrom. Simple fix is to hold down the user button when booting, which will bypass NAND and boot straight from the SD card, which presumably has the version of u-boot you just built. You can then stop the boot and either zero out the NAND or flash the current MLO and u-boot into it.
After that, you'll run into some more issues if you're using an image based on systemd. The meta-ti layer controls the basic parameters for the 'beagleboard' configuration and has its virtual/kernel provider set to linux-mainline, which is also in the meta-ti layer. At some point there was a new recipe version added for it which builds a 3.14 kernel, but the kernel configuration isn't suitable for systemd and the system will hang shortly after booting.
The good news is that Angstrom v2013.06 predates the 3.14 kernel change in meta-ti, and I was able to get that running just fine. I am trying to get a more recent Angstrom working with the 3.2 kernel that works with v2013.6, but I haven't had any luck yet.