According to the document "BCM2711 ARM Peripherals" Version 1, 5th February 2020, at page 83, "The GPIO base address is 0x7E21 5000."
(The link to the document is this: BCM2711 ARM Peripherals.)
From the command prompt, when I enter, "cat /proc/iomem", it displays, among other things, "gpio#7e200000".
My question is: Shouldn't these numbers be the same?
Yes, these numbers should indeed be the same.
Today I discovered that there is an error in the BCM2711 ARM Peripherals datasheet, also see this GitHub issue.
The correct GPIO base address is 0x7E20 0000.
Related
I've got a Raspberry Pi CM4 (with eMMC) running an image built using Yocto. The CM4 is running on the official CMIO board.
I want to use the official Raspberry Pi 7" Display on this, using the DSI interface, but I have trouble getting it working. The display does not turn on at all. I need help configuring my image, or my yocto build correctly to allow me to use this display.
What worked:
It works as expected on a Raspberry Pi 4 Mode B. I can flash my Yocto-based image to an SD card and the device boots as expected with the display working
It works on the CM4 using the official Raspberry Pi OS image, but only after I do one of the following:
a. Add the dt-blob.bin file as described in the Compute Model Documentation
b. I add the following line to the config.txt file in the boot folder: dtoverlay=vc4-fkms-v3d
Issue:
When I flash my Yocto-based image to the Raspberry Pi, the screen does not work. The device boots up, and I can get an output through HDMI, but not through the DSI interface.
What I have tried
I've downloaded the dt-blob.bin file to both the /uboot/ and /boot/ folders on my device and rebooted, but it had no effect
I added the vc4-kms-dsi-7inch dtbo to the /uboot/overlays folder and added dtoverlay=vc4-fkms-v3dto config.txt in /uboot/ and it still didn't have any effect.
It feels like this is a device-tree related issue. And I imagine there is some difference in pin usage between the Raspberry Pi 4B and the CM4, which makes my image not work on the CM4.
One thing I did note, the image I'm using has dtoverlay=vc4-fkms-v3d in config.txt while the official image has dtoverlay=vc4-kms-v3d. I don't know if that makes a difference, but changing it on my image to fkms and rebooting didn't have any effect.
This is an extract from the local.conf file for my yocto build:
MACHINE ?= "raspberrypi4"
ENABLE_DWC2_HOST = "1"
RPI_USE_U_BOOT = "1"
MENDER_BOOT_PART_SIZE_MB = "40"
IMAGE_INSTALL_append = " kernel-image kernel-devicetree"
IMAGE_FSTYPES_remove += " rpi-sdimg"
MENDER_FEATURES_ENABLE_append = " mender-uboot mender-image-sd"
MENDER_FEATURES_DISABLE_append = " mender-grub mender-image-uefi"
MENDER_SERVER_URL = "https://hosted.mender.io"
MENDER_TENANT_TOKEN = [censored]
This build uses the meta-raspberrypi and meta-rpi64 layers.
Any help to understand the problem and get this display working would be appreciated.
Thanks!
I managed to solve this issue in the end.
The local.conf file had another conflicting MACHINE ?= "raspberrypi3-cm" command.
I removed this and created the image again.
Then, while still connected to the PC as a storage device, I added the dt-blob.bin file to the /boot/ drive.
I then booted up the CM4, and the display worked.
Next step would be to figure out how to implement that device tree overlay into the yocto build, but that's out of the scope of this question.
The GPIO pins are like P0.00, P0.01, P1.01, P1.02 and so on. I didnt know how to use this.
I would like to know, how to use the GPIO pins in nRF52840 for simple LED and push button circuit?
It would be really helpful.
The GPIO pins on the nRF52840 development kits are mapped as follows:-
P0.00 - P0.31 : SIO0 - SIO31
P1.00 - P1.15 : SIO32 - SIO47
In other words, P0.01 is SIO1, P1.01 is SIO33, P1.02 is SIO34 and so on. The macro mapping can be found in Nordic_SDK/modules/nrfx/hal/nrf_gpio.h (Line 71).
I have created a Linux device driver and can add it to the system (insmod, mknod). When I look in /dev I see it listed as camerax:
ls -l /dev/camerax
crw-r--r-- 1 root root 245, 0 Jun 27 17:19
Even so, I cannot access it. Whatever I do, I get an error.
For example:
int fd = open("/dev/camerax", O_RDONLY);
printf("%d [%s]\n", fd, strerror(errno));
Generates:
-1 [No such device or address]
I'm running as a super user. Any suggestions?
Your Module is not linked to the special file which you have mentioned so it is giving error.
If your module is successfully inserted verify in /proc/devices using cat command
cat /proc/devices.
file created using mknod in the path /dev/____ is just a refrence to your driver
The major and minor number should match with your inserted device.
I have solved the problem.
Instead of creating the major device number dynamically, as described in the documentation, I now set it explicitly to 61. Everything now works.
The only difference I can see between the working and non-working versions is the major number (and yes, I change anything that uses the device number so I am always using the appropriate one).
This adds one more bizarre feature of the system to my growing list.
I am trying to use Octave in Win 7, 64 bit. I installed cygwin64, with octave, gnuplot and x11. However, when I start the X server and opened octave, trying to plot, it came up with this:
octave:1> plot(1:10)
0 [main] octave-3.6.4 5560 child_info_fork::abort: C:\cygwin64\bin\cygoctave-1.dll: Loaded to different address: parent(0xF30000) != child(0xE90000)
error: popen2: process creation failed -- Resource temporarily unavailable
error: called from:
error: /usr/share/octave/3.6.4/m/plot/private/__gnuplot_open_stream__.m at line 30, column 44
error: /usr/share/octave/3.6.4/m/plot/__gnuplot_drawnow__.m at line 72, column 19
Would anyone please help a little bit here?
Thank you!
-Shawn
Got it solved. I got the answer from the cygwin mailing list, as follows:
The problem is, the hash algorithm used by ld to compute a default DLL
load address is not exactly bullet proof, not even with such a big
address space we have now available for DLLs. It still requires to
run rebase to be on the safe side.
However, I just found a problem in the 64 distro which results in not
running autorebase as part of an update. This should be fixed soon.
For the time being, stop all Cygwin processes, start a naked dash and
run /usr/bin/rebaseall.
All credit goes to Corinna.
I have written a small program to detect whenever a device is mounted on a desktop running Linux. I have used GIO for this. I am extracting the URI of the mounted resource and displaying it to the user. When I put in a CD I get a URI string which looks like file:///media/cdrom0/ which I can understand. But when I mount an iPod the URI I see is something like gphoto2://[usb:002,028]. What does this mean? I have observed that the second number (028) keeps increasing every time I take the device out and plug it back in. Can some one interpret this URI for me?
Update: As shodanex answered, the two numbers are the bus number and device number respectively. gphoto2:// indicates the protocol (PTP/MTP).
gphoto2://[usb:002,028]
I guess 002 is the bus number, and 28 is the adress of the device on that bus.
It maps to the second and fourth field of the lsusb util output. Here is an example
on my system :
Bus 001 Device 015: ID 05e3:0715 Genesys Logic, Inc. USB 2.0 microSD Reader
I guess it would translate to :
usb:001,015
I have these kinds of URL's in Nautilus too, but the other response doesn't explain how that relates to a mount location on disk. I can navigate through the files on an SD card via the Nautilus file browser, but I don't see any of these files in /mnt/ or /media/ or anywhere else I would typically look for automatically mounted file systems.
Eventually I tried right-clicking the folder, selecting "Open with other application," choosing a text editor, and then I could see that the folder was actually mounted at:
'~/.gvfs/gphoto2 mount on usb%3A001,010'
I wish Nautilus and other tools in ubuntu would provide some more obvious way to find these files... this seems pretty un-intuitive.