I am using ARMv8/ARM64 Architecture and booting Linaro v4.9 lsk . I want to use ACPI sleep state S3 like below:
echo mem > /sys/power/state
I got an error :
Invalid argument
The only strings present in /sys/power/state are "freeze" and "mem"
I am also using ARM trusted Firmware and after so much efforts to get any clue to make it work .I found out that it is supported with psci 1.0 which is already there in my Firmware..
Can anybody let me know what i am missing?
I have tried to change device tree also to take psci-1.0...if there is really a device tree entry needed..please let me know the exact entries for making Suspend to Ram work.
Thanks in Advance
Related
Currently i am trying to get the STM32F405 to jump to bootloader from application code without the use of the boot0 and boot1 pins.
I did already try multiple things to get that done but it always ended with the the firmware jumping to the bootloader (at least it seems like it) and after approximate 18 seconds the firmware restarts (no Watchdog or similar things that could wake the chip up again are used as far as i know).
During those 18 seconds if i try to update the firmware the bootloader doesn't get found.
I tested things like:
1. (STM32F4 Jump to Bootloader via SoftReset and without BOOT0 and BOOT1 Pin)
Set a value in SRAM
Restart the STM32F405 with NVIC_SystemReset() to get the STM32F405 to close reset condition
Check for value in SRAM ( if it's set do the following )
Move stackpointer to bootloader address
Jump to bootloader address + 4 (0x1FFF0000 + 4)
2.
During runtime call function JumpToBootloader()
Within that function disable interupts, reset SysTick, reset SYSCLK, call RCC_DeInit()
Move stackpointer to bootlader address
Jump to bootloader address + 4 (0x1FFF0000 + 4)
One approach i found but couldn't test yet was to do basically what i discribed in try 1. but using assembler code within the STM32F4xx startup file.
The problem here is that the tutorial i found uses the KEIL assembler syntax which i cant use because i use the Atollic TrueSTUDIO and i have not enough knowlege about assembler to change the KEIL syntax to standard assembler syntax.
The thing that confuses me the most is that in an other project i use an STM32F3xx (cant remeber the correct number) and i do basically the same thing as in try 2. but with the the bootloader address of the STM32F3xx (0x1FFFD800) and it works perfectly fine and i can update the firmware via USB.
So the questions i have:
What could i try next to get the bootloader running?
What could be the cause in my current situation for the firmware to restart after X seconds?
A few days ago i found the cause of the problem i had.
Within the "system_stm32f4xx.c" the I2S clock got configurated and in my project that clocks doesnt get used.
Im not 100% sure why, but after removing this block of code everything works perfectly fine.
(sorry for late answer, kind of forgot about the post :D)
Coming form this question yesterday, I decided to port this library to my board. I was aware that I needed to change something, so I compiled the library, call it on a small program and see what happens. The 1st problem is here:
// Check for GPIO and peripheral addresses from device tree.
// Adapted from code in the RPi.GPIO library at:
// http://sourceforge.net/p/raspberry-gpio-python/
FILE *fp = fopen("/proc/device-tree/soc/ranges", "rb");
if (fp == NULL) {
return MMIO_ERROR_OFFSET;
}
This lib is aimed for Rpi, os the structure of the system on my board is not the same. So I was wondering if somebody could tell me where I could find this file or how it looks like so I can find it by my self in order to proceed the job.
Thanks.
You don't necessarily want that "file" (or more precisely /proc node).
The code this is found in is setting up to do direct memory mapped I/O using what appears to be a pi-specific gpio-flavored version of the /dev/mem type of device driver for exposing hardware special function registers to userspace.
To port this to your board, you would need to first determine if there is a /dev/mem or similar capability in your kernel which you can activate. Then you would need to determine the appropriate I/O registers for GPIO pins. The pi-specific code is reading the Device Tree to figure this out, but there are other ways, for example you can manually read the programmer's manual of the SoC on which you are running.
Another approach you can consider is adding some small microcontroller (or yes, barebones ***duino) to the system, and using that to collect information from various sensors and peripherals. This can then be forwarded to the SoC over a UART link, or queried out via I2C or similar - add a small amount of cost and some degree of bottleneck, but also means that the software on the SoC then becomes very portable - to a different comparable chip, or perhaps even to run on a desktop PC during development.
I am trying to access intel (cavecreek) gpio controller from user space. But I am getting: "NO such device " error when trying to echo to /sys/class/gpio/export :
echo 32 > /sys/class/gpio/export
bash: echo: write error: No such device
The error message seems to suggest that i need to have a device connected to the gpio. But documentation doesn't seem to mention that.
Nothing is being reserved as far as I can tell from dumping out /sys/kernel/debug/gpio.
I have a i2c mux connected to the gpio pins.
Below is more info on my kernel and configuration
the kernel is is 3.14
here's the relevant config setting:
CONFIG_ARCH_WANT_OPTIONAL_GPIOLIB=y
CONFIG_GPIOLIB=y
CONFIG_GPIO_DEVRES=y
CONFIG_GPIO_ACPI=y
CONFIG_DEBUG_GPIO=y
CONFIG_GPIO_SYSFS=y
in my case, the problem was with the kernel source 3.14.
my system uses intel rangely. in the source lpc_ich.c, .gpio_version field is missing for LPC_DH89XXCC.
i added that field, recompiled and kernel was able to enumerate gpiopin, although the display for the default gpio direction is not correct. direction always shows 'in' for all pins initially, but after using echo command to change the pin direction, the display will show up correctly.
Currently I'm trying to check the booting time of an Tixi board using systemd on a 2.6.39 linux kernel. To do so I created a service file that calls a bash script which sets and uses a gpio. The problem is that my systems is not allowing me to change the value of the gpio. I can sucessfully export it, change its direction, but NOT the value. I have connected an oscilloscope to check if the value had changed in the hardware but not updated in the file as suggested in some forums, but it was the same: the value just doesn't change!
I should also point out that the same script is working if I use system V, with exactly the same coonfiguration for the kernel, busybox and filesystem.
It is very ironic because I'm already the root of the systems, nevertheless even changing the permissions of the file, would not allow me to change its value. There is also no feedback from the kernel saying that the operation was not possible, but rather it looks as if it was possible but when I check the value, it was the same as before.
I also tried to run that in the Raspbian with a 3.12 (which I changed to systemd) and it was in fact possible to do it, just in the normal way from userspace.
I would appreciate if you have any idea oh what might be the problem since I already run out of ideas.
Thanks
PS: This is the code that should work on the bash line:
echo 0 > /sys/class/gpio/gpio104/value
more /sys/class/gpio/gpio104/value
// I get 1 not 0 as I requested
Nevertheless the same lines of code in the same board work if I use systemV but not if I use systemd
Probably cause by the lack of udev in your new setup which change the permission for those gpio in /sys/class. You might want to just put back udev to see if it fixes your problem.
I don't know your image setting, but each gpio pins needs to be exported prior to usage. Are you doing it or it's done automatically? If you have omap mux kernel switch, you do something like :
echo 0x104 > /sys/kernel/debug/omap_mux/cam_d5 (set mode 4 as stipulate in TI Sitara TRM)
echo 104 > /sys/class/gpio/export (export the pin)
echo out > /sys/class/gpio/gpio104/direction (set the pin as output)
Also do a dmesg | grep gpio and see if there's any initializing problem with the gpio mux.
Actually I've faced an issue similar to your's , ie was not able to change the value of set of gpio pin manually
Finally the result obtained was even though the name of that pin is gpio it can only be used for input only (DM3730 gpiO_114 and gpio_115).
So please refer to the datasheet and confirm it can be used for I/O operations..
From my understanding, after a PC/embedded system booted up, the OS will occupy the entire RAM region, the RAM will look like this:
Which means, while I'm running a program I write, all the variables, dynamic memory allocated in the stacks, heaps and etc, will remain inside the region. If I run firefox, paint, gedit, etc, they will also be running in this region. (Is this understanding correct?)
However, I would like to shrink the OS region. Below is an illustration of how I want to divide the RAM:
The reason that I want to do this is because, I want to store some data receive externally through the driver into the Custom Region at fixed physical location, then I will be able to access it directly from the user space without using copy_to_user().
I think it is possible to do that by configuring u-boot, but I have no experience in u-boot, can anyone give me some directions where to begin with, such as: do I need to modify the source of u-boot, or changing the environment variables of u-boot will be sufficient?
Or is there any alternative method of doing this?
Any help is much appreciated. Thanks!
p/s: I'm using TI ARM processor, and booting up from an SD card, I'm not sure if it matters.
The platform is ARM. min_addr and max_addr will not work on these platform since these are for Intel-only implementations.
For the ARM platform try to look at "mem=size#start" kernel parameter. Read up on Documentation/kernel-parameters.txt and arch/arm/kernel/setup.c. This option is available on most new Linux code base (ie. 2.6.XX).
You need to set the following parameters:
max_addr=some_max_physical
min_addr=some_min_physical
to be passed to the kernel through uboot in the 'bootargs' u-boot environment variable.
I found myself trying to do the opposite recently - in other words get Linux to use the additional memory in my system - although I'm using Barebox rather than u-boot on a OMAP4 platform.
I found (a bit to my surprise) that once the Barebox MLO first stage boot-loader was aware of the extra RAM, the kernel then detected and used it as well without any bootargs. Since the memory size is not passed anywhere on the boot-line, I can only assume the kernel inspects the memory mappings set up by the boot-loader to determine RAM size. This suggests that modifying your u-boot to not map all of the RAM is the way to go.
On the subject of boot-args, there was a time when you it was recommended that you mapped out a chunk of RAM (used by the frame buffer?) on OMAP4 systems, using the boot-line. It's still unclear whether this is still necessary.