I installed a bitcoin node using a raspberry-pi 2 + usb stick of 128 Giga (hosting the blockchain). But cannot make it run. This is what i get:
$ bitcoind
Segmentation fault
After googling a while, the possible causes I found are:
Corrupted SD card or program
Electric supply issue (lack of voltage)
Hopefully it's non of them. Any insight or advice?
Related
I have been trying to locate a working library for the MSR605X magnetic card reader/writer. At time of writing, I have tried five separate libraries. Only two of these were explicitly for the 605X the other three were for the older 605. All the libraries I have tried either did nothing at all or errored before completing a command (can't figure out the errors either).
I am running Raspberry Pi OS 32 bit on a Raspberry Pi 3 B+ the MSR605X communicates via a USB connection.
So far the library that seems to be most complete is: https://pypi.org/project/msrx/
However, I can not get this library to read or write (either nothing happens or I get a Serial exception "cannot reconfig port).
Any help or links to documentation for this reader is welcome.
EDIT: Adding the commands ran with the above library
msrx -D /dev/input/event4 read
msrx -D /dev/input/jso0 read
The -D is to specify the device path (default is /dev/ttyUSB0 which doesn't exist on my system). I obtained the above two paths by searching for USB serial devices then matching the search result to the device ID which I obtained from lsusb.
Running these commands results in a serial exception (could not reconfig port) which I assume means that I have the wrong device path. I have also checked for any tty* device paths that are changed when I plug in the reader. I consistently get a permission denied error whenever trying to run the above commands with a tty* device path (I am root on this system).
msrx author here — MSR605 requires an external 9V power injected into its cable (via the barrel jack port), otherwise it won't power up properly.
I've recently been getting into bare metal development for the Raspberry Pi 2, and having some success. Admittedly I've hesitated to buy an actual physical device until I feel I can do something useful with it, for the time being I've been emulating the device using qemu 2.11.0.
So far I've developed multicore capabilities for my kernel, as well as simple Serial I/O, but I feel I'd like to get much further before working with a physical device.
My issue right now is that I'm trying to learn how to place my kernel onto an SD card image and boot qemu-system-arm from that SD card image, so I can properly emulate a kernel loaded from the raspberry pi 2 bootloader.
I've gotten as far as grabbing the SD card contents from https://github.com/raspberrypi/firmware ... aster/boot, and using the following script to create the image and load my kernel into it. I've seen that people have figured out how to load Raspbian from an emulated SD card, so I figure I can do the same.
#!/bin/bash
OUTPUT_IMG=os.img
OUTPUT_IMG_SIZE=40
TEMP_MOUNT_DIR="$(mktemp -d)"
# the SD card boot partition contents are in this folder...
OUTPUT_IMG_CONTENTS_DIR="./sd"
OS_DIR="${HOME}/os"
OS_BINARY="${OS_DIR}/kernel.bin"
dd if=/dev/null of=${OUTPUT_IMG} bs=1M seek=${OUTPUT_IMG_SIZE}
mkfs.fat -F 32 ${OUTPUT_IMG}
sudo mount -t vfat -o loop ${OUTPUT_IMG} ${TEMP_MOUNT_DIR}
make -C ${OS_DIR} clean
make -C ${OS_DIR}
sudo cp -r ${OUTPUT_IMG_CONTENTS_DIR} ${TEMP_MOUNT_DIR}
sudo cp ${OS_BINARY} "${TEMP_MOUNT_DIR}/kernel.img"
The only issue is that qemu doesn't seem to boot from this image using the following command:
qemu-system-arm -machine raspi2 -serial file:serial.log -sd ./dev/os.img
I've tried a few different combinations, but to no avail.
I can see from hooking GDB that the kernel is simply not booting from this card image. Loading the kernel directly into qemu with the -kernel argument works otherwise perfectly.
I was wondering if anyone here had any insight on how to accomplish this!
Any help here would be greatly appreciated!
Your command won't work because you haven't passed QEMU either a guest BIOS or a guest kernel to run. The QEMU arm boards aren't like the x86 PC machine, which always automatically runs a guest BIOS image. If you want to run a BIOS (probably UEFI?) you need to find a suitable BIOS blob and pass it to QEMU with the -bios argument. Then QEMU will run the BIOS code, which will hopefully include SD card drivers to load the kernel and so on off the SD card.
Just using -kernel is much simpler...
After doing a bit of reading and searching online, as well as a bit of help from other contributors such as Peter Maydell with his answer above, I think I've answered my own question. Unless I'm mistaken qemu-system-arm does not fully emulate the Raspberry Pi boot process, and instead just loads the kernel specified with the -kernel argument by loading the binary into the guest system's memory and jumping to the entry point. It doesn't look like any additional hardware bootloading is emualted for -M raspi2 unfortunately.
Can ARM qemu system emulator boot from card image without kernel param?
This question is similar and contains some more useful details on this issue, relating to qemu-system-arm as a whole..
I am currently developing a small OS on my Raspberry Pi, that I install by replacing the kernel.img file on the /boot partition of my SD card. By the time my code is run, the CPU is already in Normal Mode, so I can't have access to the Secure world / Trustzone area.
Is it possible to modify the boot process of the Raspberry to be able to start executing my code in Secure mode ?
Best,
V.
In fact you don't have to do anything but stop being stupid like me.
As explained here:
https://raspberrypi.stackexchange.com/questions/14953/is-it-possible-to-boot-the-raspberry-pi-in-secure-mode
When the NS bit of the SCR register is 0, it means that you are in Secure Mode, which is the case at boot on my Raspberry. I had the meaning of this bit backwards, sorry !
I am having some real problems now with TIBCO RV, at the exact same time two machines reported dataloss on INBOUND. The 3rd machine, the remote daemon, did not report any unusual errors. This is happening too often, even though I've manually changed the rx/tx buffer size on network cards. I am not using CDM. Any ideas? Thanks
Machine 1
2013-01-08 12:58:21 /usr/tibco/tibrv/bin/realrvd64: TIB/Rendezvous Error: {ADV_CLASS="ERROR" ADV_SOURCE="SYSTEM" ADV_NAME="DATALOSS.INBOUND.BCAST" ADV_DESC="dataloss: remote daemon did not satisfy our retransmission request(s)" host="Machine 3" lost=3 scid=13001}
Machine 2
2013-01-08 12:58:21 /usr/tibco/tibrv/bin/realrvd64: TIB/Rendezvous Error: {ADV_CLASS="ERROR" ADV_SOURCE="SYSTEM" ADV_NAME="DATALOSS.INBOUND.BCAST" ADV_DESC="dataloss: remote daemon did not satisfy our retransmission request(s)" host="Machine 3" lost=3 scid=13001}
I have a fc14 32 bit system with 2.6.35.13 custom compiled kernel.
When I try to start G-wan I get a "Segmentation fault".I've made no changes, just downloaded and unpacked the files from g-wan site.
In the log file I have:
"[Wed Dec 26 16:39:04 2012 GMT] Available network interfaces (16)"
which is not true, on the machine i have around 1k interfaces mostly ppp interfaces.
I think the crash has something to do with detecting interfaces/ip addresses because in the log after the above line I have 16 lines with ip's belonging to the fc14 machine and after that about 1k lines with "0.0.0.0" or "random" ip addresses.
I ran gwan 3.3.7 64-bit on a fc16 with about the same number of interfaces and had no problem,well it still reported a wrong number of interfaces (16) but it did not crashed and in the log file i got only 16 lines with the ip addresses belonging to the fc16 machine.
Any ideas?
Thanks
I have around 1k interfaces mostly ppp interfaces
Only the first 16 will be listed as this information becomes irrelevant with more interfaces (the intent was to let users find why a listen attempt failed).
This is probably the long 1K list, many things have changed internally after the allocator was redesigned from scratch. Thank you for reporting the bug.
I also confirm the comment which says that the maintenance script crashes. Thanks for that.
Note that bandwidth shaping will be modified to avoid the newer Linux syscalls so the GLIBC 2.7 requirement will be waved.
...with a custom compiled kernel
As a general rule, check again on a standard system like Debian 6.x before asking a question: there is room enough for trouble with a known system - there's no need to add custom system components.
Thank you all for the tons(!) of emails received these two last days about the new release!
I had a similar "Segmentation fault" error; mine happens any time I go to 9+GB of RAM. Exact same machine at 8GB works fine, and 10GB doesn't even report an error, it just returns to the prompt.
Interesting behavior... Have you tried adjusting the amount of RAM to see what happens?
(running G-WAN 4.1.25 on Debian 6.x)