I'm seeing a curious problem when trying to load device tree overlays on a Beaglebone black. The loader fails to load the .dtbo file because it is looking for a file with a name different to the one it has been told to load. The .dts file was compiled on the same device using the command:
dtc -O dtb -o TEST-DT-00A0.dtbo -b 0 -# TEST-DT-00A0.dts
The compilation completed without errors but when I attempt to load the binary using:
echo TEST-DT-00A0.dtbo > /sys/devices/bone_capemgr.9/slots
I see the error:
-bash: echo: write error: No such file or directory
Examining the reason for the failure using dmesg reveals that the loader was attempting to load a file with the name (-0 inserted into the file name):
TEST-DT-0-00A0.dtbo
Sure enough, if I rename the .dtbo file to the name expected by the loader it loads correctly and works just fine.
Does anyone have any idea why the extra '-0' was added to the name by the device tree loader? On a second Beaglebone, the loader was expecting the file to be named TEST-DT-00-00A0.dtbo (-00 added to the name).
If it helps, here's the output from uname:
Linux beaglebone 3.8.13-bone79 #1 SMP Tue Oct 13 20:44:55 UTC 2015 armv7l GNU/Linux
Thanks for any help!
It appears the device tree loader is a little simplistic and assumes the filename has exactly 16 characters in its name. If the device tree fragment does not have a 16 character name then various level of padding or truncation can occur when the fragment is loaded.
The correct thing then would be for the above fragment to be renamed to something like:
TEST-DT-12345678-00A0.dtbo
(16 characters before the -00A0.dtbo)
Then this would load correctly with the device tree loader mangling the name.
Also, be wary of trying to load a file with a path:
echo /lib/firmware/TEST-DT-12345678-00A0.dtbo > /sys/devices/bone_capemgr.*/slots
The characters in the path will count towards the 16 character expected name length resulting in the device tree loader attempting to load the fragment:
TE-00A0.dtbo
If you are experiencing 'No such file or directory' errors when trying to load a fragment, be sure to check dmesg!
Please note, that Device Tree Overlays are now obsolete, and Uboot should be used to config at boot or config-pin command.
Check here section: Where did the slots file go?
https://elinux.org/Beagleboard:BeagleBoneBlack_Debian#U-Boot_Overlays
Example of UART4 config-pin script
#!/bin/sh
config-pin p9.11 uart
config-pin p9.13 uart
stty -F /dev/ttyO4 sane
I have built a linux image for ARM on Ubuntu. I was curious to use the file command on the image file created in arch/arm/boot directory. When i execute the following the command
balaji#balaji-virtual-machine:~/meraj/linux-stable/arch/arm/boot$ ls
bootp compressed dts Image install.sh Makefile zImage
balaji#balaji-virtual-machine:~/meraj/linux-stable/arch/arm/boot$ file Image
Image: data
balaji#balaji-virtual-machine:~/meraj/linux-stable/arch/arm/boot$ file zImage
zImage: data
balaji#balaji-virtual-machine:~/meraj/linux-stable/arch/arm/boot$
It gives not much information. I would like to know if this is expected behaviour or not?
From file manpage:
The type printed will usually contain one of the words...
... "data" meaning anything else (data is usually 'binary' or non-printable).
Exceptions are well-known file formats (core files, tar archives) that
are known to contain binary data.
Also...
Any file that cannot be identified as having been written in any of
the character sets listed above is simply said to be 'data'.
I wan't to find the kernel address of system call table.
I usually do this by grepping sys_call
but in one system, I can see the address
but in other, it doesn't show the entry.
root#ubuntu:~# cat /proc/kallsyms | grep sys_call
ffffffff8122aa90 t proc_sys_call_handler
ffffffff81726432 t ret_from_sys_call
ffffffff81726644 T int_ret_from_sys_call
ffffffff81728146 t sysexit_from_sys_call
ffffffff81728386 t sysretl_from_sys_call
ffffffff8172858e t ia32_ret_from_sys_call
**ffffffff81801400 R sys_call_table**
ffffffff81809cc0 R ia32_sys_call_table
root#ubuntu:~#
no system call table... why not showing the R type symbol??
/ $ cat /proc/kallsyms | grep sys_call
ffffffff8119c230 t proc_sys_call_handler
ffffffff817a1a57 t ret_from_sys_call
ffffffff817a1c50 T int_ret_from_sys_call
ffffffff817a2cb8 t sysexit_from_sys_call
ffffffff817a2ed8 t sysretl_from_sys_call
ffffffff817a30be t ia32_ret_from_sys_call
/ $
/ $
in what case does this could happen?
some advice would be nice
thank you
You should look into the version of the kernel in both cases, check with uname -r.
This was initially exported in the earlier versions of the kernel 2.4.x. This initially had "EXPORT_SYMBOL(sys_call_table);" line from linux/kernel/ksyms.c for
sys_call_table from being exported properly and later was made static and removed IMU.
Now this has been exported again in of some of latest kernels (in some version > 3.3.x). I would recommend digging into the LXR to check out the details.
You need to check whether your current kernel is compiled with the option CONFIG_KALLSYMS_ALL=y
I am working to enable spi on my beaglebone black (Angstrom distribution), using instructions here.
I am at the point where i need to add BB-SPI1-01 to /sys/devices/bone_capemgr.*/slots to enable the drivers.
issuing the command echo BB-SPI1-01 > /sys/devices/bone_capemgr.*/slots or echo BB-SPI1-01 >> /sys/devices/bone_capemgr.*/slots, however, yields the error echo: Write error: file exists
Trying to edit in the line with nano also fails. I'm able to open the file and edit it, but when I save it gives me Error writing slots: no such file or directory
I've set permissions on the file to 777.
Does anybody know why I cannot edit the file? if it's not possible, is there a workaround?
I, too have battled with this dilemma while trying to port ILI9340C display stuff to Beaglebone Black. The way /dev/devices/bone_capemgr.* works is that anything which you echo to its slots directory it goes and searches for a Device Tree overlay for that device, a new thing in Linux Kernel 3.0 and higher. For anyone who does not know (it took me forever to find this) Device Trees are basically a driver that tells Linux how to deal with a device, but instead of containing any code, they are simply a configuration file, per-se, that tells Linux what to put where in order to talk to a device, and what to expect in return. That being said, BB-SPIx-01 is a compiled Device Tree file, a .dts in /lib/firmware/ which points to the SPI device, and tells spidev what to do with it.
BB-SPI1-01 happens to be connected to the HDMI port already for some audio thing (I think) and, therefore, unless you disable HDMI entirely, SPI1 is always tied up by the HDMI framer. This explains why writing BB-SPI1-01 to /sys/devices/bone_capemgr.*/slots fails. This is a special file, and when you write to it, a kernel process reads your input and proceeds to attempt to make a 'device' file elsewhere, and since BB-SPI1-01 is already enabled, that file already exists, and so the kernel process that handles those things returns an error and pipes it through whatever process initiated it, in this case, you, the user, typing echo BB-SPI1-01 > /sys/devices/bone_capemgr.*/slots.
On the bright side, SPI0 is left unused. Therefore, in order to use it, all you have to do is enable it in userland. To do that, (and you have figured this out already, but for everyone else) type echo BB-SPI0-01 > /sys/devices/bone_capemgr.*/slots at the command line, and then just to be sure that spidev is running, type modprobe spidev as root. Now, to verify, type ls /dev | grep spi and see what comes up. /dev/spidevX.Y is your SPI bus, for me that would be /dev/spidev1.0.
I'm sorry that was really long winded, but I'm culminating my research thus far into one spot in the hopes that it will help someone.
If you have any questions, please feel free to ask!
For those who are curious, while I haven't found the exact answer, I did find some more information.
The SPI1 interface on the beaglebone black can't be enabled unless the hdmi interface has been turned off, which I have not done. I'm instead using the SPI0 interface now. Interestingly, that same command works if BB-SPI0-01 is used instead of BB-SPI1-01. Therefore the error in question is probably not coming from the base command, but rather the system in response to the command (which can't allocate the resources requested due to conflicts with hdmi).
While I haven't tested SPI1 with hdmi turned off, I can only assume that my errors would go away.
Might it be because you're trying to access more than one file at a time with echo BB-SPI1-01 > /sys/devices/bone_capemgr.*/slots ?
Try selecting single path to the slots file and see if that works
Based on PyroAVR's answer, here is the concrete solution. You need to disable HDMI, that's easily done by editing the following file: /boot/uEnv.txt
You can uncomment the line which causes HDMI to be disabled by running the following command as root:
sed -i.bck '/cape_disable=capemgr.disable_partno=BB-BONELT-HDMI,BB-BONELT-HDMIN$/ s/^#//' /boot/uEnv.txt
as Mixaz mentioned in a comment, the real errors are found in the dmesg output; "no such file or directory" is a red herring, and even strace doesn't give any clues as to the real problem. in my case I found:
[26858.517893] bone_capemgr bone_capemgr: slot #5: override
[26858.517937] bone_capemgr bone_capemgr: Using override eeprom data at slot 5
[26858.517986] bone_capemgr bone_capemgr: slot #5: 'Override Board Name,00A0,Override Manuf,jc_gpio_test'
[26924.230357] bone_capemgr bone_capemgr: part_number 'jc_gpio_test', version 'N/A'
from that I guessed that it didn't like "0000" as a version number, changed to "00A0" and recompiled, then it worked.
here's the Makefile I wrote to help automate the process, in case it helps.
%.install: %-00A0.dtbo
cp -f $< /lib/firmware
echo $* > /sys/devices/platform/bone_capemgr/slots
%-00A0.dtbo: %.dts
dtc -O dtb -o $# -b 0 -# $<
use it as: make jc_gpio_test.install, assuming your .dts file name is jc_gpio_test.dts.
it turns out, my guess was probably wrong. the change that more likely fixed it was adding the -00A0 part to the dtbo file. apparently the "dash-versionnumber" is required by the slot loader.
Is there way to compress the core files during core dump generation?
If the storage space is limited in the system, is there a way of conserving it in case of need for core dump generation with immediate compression?
Ideally the method would work on older versions of linux such as 2.6.x.
The Linux kernel /proc/sys/kernel/core_pattern file will do what you want: http://www.mjmwired.net/kernel/Documentation/sysctl/kernel.txt#191
Set the filename to something like |/bin/gzip -1 > /var/crash/core-%t-%p-%u.gz and your core files should be saved compressed for you.
For an embedded Linux systems, following script change perfectly works to generate compressed core files in 2 steps
step 1: create a script
touch /bin/gen_compress_core.sh
chmod +x /bin/gen_compress_core.sh
cat > /bin/gen_compress_core.sh #!/bin/sh exec /bin/gzip -f - >"/var/core/core-$1.$2.gz"
ctrl +d
step 2: update the core pattern file
cat > /proc/sys/kernel/core_pattern |/bin/gen_compress_core.sh %e %p ctrl+d
As suggested by other answer, the Linux kernel /proc/sys/kernel/core_pattern file is good place to start: http://www.mjmwired.net/kernel/Documentation/sysctl/kernel.txt#141
As documentation says you can specify the special character "|" which will tell kernel to output the file to script. As suggested you could use |/bin/gzip -1 > /var/crash/core-%t-%p-%u.gz as name, however it doesn't seem to work for me. I expect that the reason is that on my system kernel doesn't treat the > character as a output, rather it probably passes it as a parameter to gzip.
In order to avoid this problem, like other suggested you can create your file in some location I am using /home//crash/core.sh, create it using the following command, replacing with your user. Alternatively you can also obviously change the entire path.
echo -e '#!/bin/bash\nexec /bin/gzip -f - >"/home/<username>/crashes/core-$1-$2-$3-$4-$5.gz"' > ~/crashes/core.sh
Now this script will take 5 input parameters and concatenate them and add to core-path. The full paths must be specified in the ~/crashes/core.sh. Also the location of this script can be specified. Now lets tell kernel to use tour executable with parameters when generating file:
sudo sysctl -w kernel.core_pattern="|/home/<username>/crashes/core.sh %e %p %h %t"
Again should be replaced (or entire path to match location and name of core.sh script). Next step is to crash some program, lets create example crashing cpp file:
int main (){
int * a = nullptr;
int b = *a;
}
After compiling and running there are 2 options, either we will see:
Segmentation fault (core dumped)
Or
Segmentation fault
In case we see the latter, there are few possible reasons.
ulimit is not set, ulimit -c should specify what is limit for cores
apport or your distro core dump collector is not running, this should be investigated further
there is an error in script we wrote, I suggest than checking some basic dump path to check if the other things aren't reason the below should create /tmp/core.dump:
sudo sysctl -w kernel.core_pattern="/tmp/core.dump"
I know there is already an answer for this question however it wasn't obvious for me why it isn't working "out of the box" so I wanted to summarize my findings, hope it helps someone.