Accessing real frame buffer of PCI card - linux-device-driver

I am trying to access the framebuffer on my systems VGA controller card.
lscpi -vn gives:
00:02.0 0300: 8086:2a02 (rev 0c) (prog-if 00 [VGA controller])
Subsystem: 1028:022f
Flags: bus master, fast devsel, latency 0, IRQ 45
Memory at fea00000 (64-bit, non-prefetchable) [size=1M]
Memory at e0000000 (64-bit, prefetchable) [size=256M]
I/O ports at eff8 [size=8]
Expansion ROM at <unassigned> [disabled]
Capabilities: [90] MSI: Enable+ Count=1/1 Maskable- 64bit-
Capabilities: [d0] Power Management version 3
Kernel driver in use: i915
Now, I access the device and I get:
fb_base = pci_resource_start( devp, 0 ); **output: FEA00000**
fb_size = pci_resource_len( devp, 0 ); **output: 1MB**
So the range of framebuffer is FEA00000 - FEB00000
But from the lspci -vn output This region is non prefetchable.
Does that mean I am not pointing to the frame buffer at all.
Is my framebuffer at address E0000000:
The driver currently using the resource is the Intel i915
So maybe when I request region or IRQ it can clash if not shared by that driver.
If I remove the i915 rmmod it to insmod my driver, will my screen go blank.
Please help.
Thanks.

Related

Raspberry Pi CM4 UBoot NVME-access

Does anyone have a working UBoot config for accessing an NVME drive from UBoot running on a Raspberry Pi CM4?
I've compiled everything and UBoot is detecting my NVME correctly:
pci_bind_bus_devices: bus 1/pci_0:0.0: found device 0, function 0: find ret=-19
pci_find_and_bind_driver: Searching for driver: vendor=2646, device=2263
pci_find_and_bind_driver: Match found: nvme
pci_auto_config_devices: start
pci_auto_config_devices: device nvme#0
PCI Autoconfig: BAR 0, Mem, size=0x4000, address=0xc0000000 bus_lower=0xc0004000
pci_auto_config_devices: done
but it doesnt call nvme_uclass_post_probe() and therefore it doesnt create any block device.
Running the command "nvme scan" from the UBoot command line i'am getting a timeout in nvme_submit_sync_cmd(). -> ETIMEDOUT.
I'am using a Kingston A2000 SDD with the latest firmware "S5Z42109".
Does anyone have an idea?
Thanks.

stm32 factory bootloader possibly overwritten with openocd?

tl;dr: flashed firmware to 0x00000000 instead of 0x08000000, am I lost?
Hello,
my device is based on a STM32F103CBTx which came with a proprietary firmware and had readout protection on.
I connect to it with a ST-Link v2 SWDIO and SWCLK connected to PA13 and PA14 and this command:
sudo openocd -f /usr/share/openocd/scripts/interface/stlink-v2.cfg -f /usr/share/openocd/scripts/target/stm32f1x.cfg
I don't remember how I removed flash protection, but it worked as the original firmware didn't work anymore. Then I created a simple hello world firmware which pulls up and down three gpios and flashed it. The gpios are pulled up and down in 700ms intervals.
After flashing, I can't connect with openocd anymore. I forgot to specify the offset, the manual says the offset defaults to 0 and as it worked, I suppose instead of the boot loader my shitty hello world is pulling up and down some random pins happily… Is this possible? All other threads I found say the boot loader is write protected.
This is the last contact I had:
> halt
halt
target halted due to debug-request, current mode: Handler HardFault
xPSR: 0x01000003 pc: 0xfffffffe msp: 0xffffffdc
> flash write_image erase fw.hex
flash write_image erase fw.hex
auto erase enabled
target halted due to breakpoint, current mode: Handler HardFault
xPSR: 0x61000003 pc: 0x2000003a msp: 0xffffffdc
wrote 4096 bytes from file fw.hex in 0.285697s (14.001 KiB/s)
> reset
reset
jtag status contains invalid mode value - communication failure
Polling target stm32f1x.cpu failed, trying to reexamine
Examination failed, GDB will be halted. Polling again in 100ms
Any directions highly appreciated.
Edit:
What I get now, also tried another st-link:
% sudo openocd -f /usr/share/openocd/scripts/interface/stlink-v2.cfg -f /usr/share/openocd/scripts/target/stm32f1x.cfg
Open On-Chip Debugger 0.10.0
Licensed under GNU GPL v2
For bug reports, read
http://openocd.org/doc/doxygen/bugs.html
Info : auto-selecting first available session transport "hla_swd". To override use 'transport select '.
Info : The selected transport took over low-level target control. The results might differ compared to plain JTAG/SWD
adapter speed: 1000 kHz
adapter_nsrst_delay: 100
none separate
Info : Unable to match requested speed 1000 kHz, using 950 kHz
Info : Unable to match requested speed 1000 kHz, using 950 kHz
Info : clock speed 950 kHz
Info : STLINK v2 JTAG v17 API v2 SWIM v4 VID 0x0483 PID 0x3748
Info : using stlink api v2
Info : Target voltage: 3.244356
Error: init mode failed (unable to connect to the target)
in procedure 'init'
in procedure 'ocd_bouncer'
flashed firmware to 0x00000000 instead of 0x08000000, am I lost?
No, it doesn't matter at all, they are the same.
After reset, the MCU loads the word at address 0 in SP, and the next one at address 4 in PC. The BOOT0 and BOOT1 pins control which memory gets mapped to 0x00000000. Usually, BOOT0 is tied low, and flash memory at 0x08000000 gets mirrored at 0x00000000.
instead of the boot loader my shitty hello world is pulling up and down some random pins happily… Is this possible? All other threads I found say the boot loader is write protected.
The factory bootloader is indeed write protected, openocd can't overwrite it.
However, your application could have reconfigured the SWD pins, by writing a wrong value in GPIOA->CRH or AFIO->MAPR, thereby preventing openocd from working. It's the most common cause of this problem.
Fortunately, there is a way to recover.
Connect under Reset
If the reset pin of the controller is held low for a while when openocd is started, the application is prevented from starting, and messing up the GPIO configuration.
Openocd can do this automatically, when
It's told to do so, the line reset_config srst_only srst_nogate is present somewhere in the configuration script.
The MCU reset pin is connected to the debugger hardware, pin 15 on an official ST-Link/V2.
Or you can do it manually, by whatever means your board provides. If you are lucky, it has a reset button, if not, you must find a way to somehow ground the MCU reset pin.
Pull the reset pin low
Start openocd
Wait until the Info : Target voltage line appears. Maybe a second longer.
Release the reset pin.
It requires a bit of trial and error, you'll get better with practice.
Then you can flash your improved application, which carefully avoids reconfiguring the SWD pins.

RPi3 with SenseHat and Yocto

I am currently working with building a Yocto Image for the RPi3 with the SenseHat installed.
The Yocto image consist of the following layers:
meta
meta-poky
meta-oe
meta-networking
meta-python
meta-raspberrypi
meta-java
an application-specific layer.
The application-specific layer is mainly tasked with loading the following kernel-modules:
i2c-dev
fb_sys_fops
syscopyarea
sysfillrect
sysimgblt
rpisense_core
rpisense_js
rpisense_fb
It also contains openssh, psplash, gcc, make, libiio, rtimulib and some other misc. packages.
My image boots nicely without the SenseHat mounted, but the boot-process stops before reaching the UART shell when it is mounted. It stays frozen until the system is reset by the watchdog.
Following is the last part of the UART output before the system freezes.
{...}
Populating dev cache
ALSA: Restoring mixer settings...
/usr/sbin/alsactl: load_state:1735: No soundcards found...
Tue Nov 1 10:01:54 UTC 2016
INIT: Entering runlevel: 5
Configuring network interfaces... [ 5.130327] smsc95xx 1-1.1:1.0 eth0: hardware isn't capable of remote wakeup
udhcpc (v1.24.1) started
Sending discover...
[ 6.662428] smsc95xx 1-1.1:1.0 eth0: link up, 100Mbps, full-duplex, lpa 0x4DE1
[ 6.688217] cfg80211: Calling CRDA to update world regulatory domain
Sending discover...
Sending select for 192.168.0.106...
Lease of 192.168.0.106 obtained, lease time 3600
/etc/udhcpc.d/50default: Adding DNS 192.168.0.20
/etc/udhcpc.d/50default: Adding DNS 192.168.0.40
done.
Starting system message bus: dbus.
Starting OpenBSD Secure Shell server: sshd
[ 9.034713] NET: Registered protocol family 10
done.
Starting rpcbind daemon...done.
Starting advanced power management daemon: No APM support in kernel
(failed.)
Starting bluetooth
bluetoothd
Starting syslogd/klogd: done
* Starting Avahi mDNS/DNS-SD Daemon: avahi-daemon
[ 9.401783] Bluetooth: Core ver 2.20
[ 9.405528] NET: Registered protocol family 31
[ 9.410088] Bluetooth: HCI device and connection manager initialized
[ 9.416576] Bluetooth: HCI socket layer initialized
[ 9.421576] Bluetooth: L2CAP socket layer initialized
[ 9.426747] Bluetooth: SCO socket layer initialized
...done.
Starting Telephony daemon
[ 9.507315] Bluetooth: BNEP (Ethernet Emulation) ver 1.3
[ 9.512765] Bluetooth: BNEP filters: protocol multicast
[ 9.518098] Bluetooth: BNEP socket layer initialized
Starting Linux NFC daemon
[ 9.624816] nfc: nfc_init: NFC Core ver 0.1
[ 9.629241] NET: Registered protocol family 39
I shoould note that I have soldered three wires onto the UART pins:
RPi3 UART pins http://www.embeddedforu.com/wp-content/uploads/2015/06/Raspberry-pi-UART-connections_thumb.png
When the system is frozen, I can still ping the device, but SSH does not work.
Any idea what might be causing this behavior?
It turned out that the problem lay within the yocto local.conf-file. The following line was set:
ENABLE_I2C = "1"
This created a second i2c-driver, which lead to one of the crashing on boot.
For any googlers out there: This flag does not need to be set. Instead make sure that the i2c-dev kernel driver is loaded at boot.
I never used the bluetooth, but it seems the system doesn't freeze, you just lose UART data when Bluetooth connects.
From here:
On the rpi3, it is normal since the BCM2837 on the Raspberry Pi3 has 2 UARTs (as did its predecessors), however to support the Bluetooth functionality the fully featured PL011 UART was moved from the header pins to the Bluetooth chip and the mini UART made available on header pins 8 & 10.
This has a number of consequences for users of the serial interface.
The /dev/ttyAMA0 previously used to access the UART now connects to Bluetooth.
I would advise you to try again having in config.txt
dtoverlay=pi3-disable-bt
enable_uart=1
And if you really need bluetooth, use
dtoverlay=pi3-miniuart-bt
And for the ssh, add "openssh" in your image recipe, and dependencies to connect like wpa-supplicant (don't forget to configure it)

Can't register rteth0 for FEC Ethernet card on SabreLite iMX6Q

I'm a new user on RTnet and try to make Rtnet work on Freescale Sabre Lite iMX6Q board. But I got an issue, RTnet can't use rt_fec.ko module driver to register rt_eth0 even though non real time driver is disable.
I'm using:
Linux kernel 3.0.43 download from Xenomai git://git.xenomai.org/ipipe-gch.git/?h=ipipe-3.0-imx6q
Xenomai 2.6 download from git.xenomai.org/xenomai-2.6.git/
RTnet 0.9.13 download from rtnet.org/download.html
Please see my kernel configuration and boot log in attached link.
Xenomai is loaded:
"*I-pipe: Domain Xenomai registered.
Xenomai: hal/arm started.
Xenomai: scheduling class idle registered.
Xenomai: scheduling class rt registered.
Xenomai: real-time nucleus v2.6.3 (Lies and Truths) loaded.
Xenomai: debug mode enabled.
Xenomai: starting native API services.
Xenomai: starting POSIX services.
Xenomai: starting RTDM services.* "
And FEC ethernet driver (non real-time driver) is loaded when kernel is booting
*"FEC Ethernet Driver
fec_enet_mii_bus: probed "*
Xenomai is built following install guideline for ARM platform from Xenomai:
http://xenomai.org/installing-xenomai-2-x/
RTnet is built by below command, because SABRE Lite use FEC ethernet card with Micrel KSZ9021 Gigabit chip so I put "--enable-fec" in configure command to build real-time driver for FEC ethernet card:
"./configure --host=armv7l-timesys-linux-gnueabi --with-rtext-config=/home/sonnguyen/rtnet-xenomai-rootfs/usr/xenomai/bin/xeno-config --with-linux=/home/sonnguyen/build/rtnet-xenomai-ipipe-imx6q --enable-rtcfg-dbg --enable-rtwlan --enable-net-routing --enable-router --enable-nomac --enable-rtcap --enable-proxy --enable-checks --enable-fec "
Then
"make DESTDIR=/home/sonnguyen/rtnet-xenomai-rootfs install"
I also changed RT_DRIVER from default value to "rt_fec" in rtnet.conf.
After kernel is booted, I ran "./rtnet start" and got this:
"RTnet: initialising real-time networking
RT FEC Ethernet Driver
./rtnet: line 385: can't create /sys/bus/pci/drivers/rt_fec/bind: nonexistent directory
initializing loopback...
RTnet: registered rtlo
RTcap: real-time capturing interface
ifconfig: SIOCGIFFLAGS: No such device
ifconfig: SIOCGIFFLAGS: No such device
RTcfg: init real-time configuration distribution protocol
RTmac: init realtime media access control
RTmac/TDMA: init time division multiple access control mechanism
ioctl: No such device
ioctl: No such device
ioctl: No such device
ioctl: No such device
ioctl (add): No such device
ioctl (add): No such device
ioctl (add): No such device
ifconfig: SIOCGIFFLAGS: No such device
Waiting for all slaves...ioctl: No such device
ioctl: No such device "
Then I tried:
"# lspci
lspci: /sys/bus/pci/devices: No such file or directory
ls /sys/bus/
ac97 hid mdio_bus platform sdio spi
event_source i2c mmc scsi serio usb "
No pci directory under /sys/bus/. Then I thought because the script can't find the ethernet physical bus, it can't register rteth0.
Then I looked into rtnet script and did some minor change. In the script it requires physical ethernet device ID (mentioned in REBIND_RT_NICS), so I tried to find out what it is and got this when make eth0 up with non real-time driver:
"eth0: Freescale FEC PHY driver [Micrel KSZ9021 Gigabit PHY] (mii_bus:phy_addr=1:06, irq=-1)
PHY: 1:06 - Link is Up - 1000/Full "
I think 1:06 is my physical bus ID, then I change the code in rtnet from:
for dev in $REBIND_RT_NICS; do
if [ -d /sys/bus/pci/devices/$dev/driver ]; then
echo $dev > /sys/bus/pci/devices/$dev/driver/unbind
fi
echo $dev > /sys/bus/pci/drivers/$RT_DRIVER/bind
done
To
echo 1:06 > /sys/bus/mdio_bus/drivers/Micrel\ KSZ9021\ Gigabit\ PHY/unbind
echo 1:06 > /sys/bus/platform/drivers/rt_fec/bind
And I tried again with "./rtnet start", this time I got this:
RTnet: initialising real-time networking
RT FEC Ethernet Driver
sh: write error: No such device
initializing loopback...
RTnet: registered rtlo
RTcap: real-time capturing interface
ifconfig: SIOCGIFFLAGS: No such device
ifconfig: SIOCGIFFLAGS: No such device
RTcfg: init real-time configuration distribution protocol
RTmac: init realtime media access control
RTmac/TDMA: init time division multiple access control mechanism
ioctl: No such device
ioctl: No such device
ioctl: No such device
ioctl: No such device
ioctl (add): No such device
ioctl (add): No such device
ioctl (add): No such device
ifconfig: SIOCGIFFLAGS: No such device
Waiting for all slaves...ioctl: No such device
ioctl: No such device
But it still said "No such device"
This is lsmod after I ran ./rtnet start
lsmod
Module Size Used by Not tainted
tdma 25691 0
rtmac 9724 1 tdma
rtcfg 58071 0
rtcap 7151 0
rt_loopback 1279 2
rtpacket 6365 0
rtudp 10738 0
rt_fec 12742 0
rtipv4 29987 2 rtcfg,rtudp
rtnet 40746 9 tdma,rtmac,rtcfg,rtcap,rt_loopback,rtpacket,rtudp,rt_fec,rtipv4
./rtifconfig
rtlo Medium: Local Loopback
IP address: 127.0.0.1
UP LOOPBACK RUNNING MTU: 1500
Only rtlo is registered.
I also tried with kernel linux without non real-time FEC driver (please refer in another config file in attached Skydrive link), but still the same issue happened.
Do you have any idea how to solve this issue? I did many search but still can not figure out how to fix it.
Because I can't attach the files to my post, so I put all of my configuration files in the link below:
https://onedrive.live.com/redir?resid=162EDF85AEBD2EFE!717&authkey=!AJ1Fjd_XiohUwes&ithint=file%2czip
Best Regards,
Nguyen Hung Son

“RAM check failed” when using j-Link to erase chip or readback

I closed SWD and JTAG by acident so that I can't download new program into developboard by j-Link.Then I try using j-flash ARM to erase chip, and error comes like this:
Connecting ...
- Connecting via USB to J-Link device 0
- J-Link firmware: V1.20 (J-Link ARM V8 compiled Dec 1 2009 11:42:48)
- JTAG speed: 2000 kHz (Auto)
- Initializing CPU core (Init sequence) ...
- Executing Reset (0, 0 ms)
- Initialized successfully
- JTAG speed: 2000 kHz (Auto)
- Connected successfully
Reading entire flash chip ...
- 64 sectors, 1 range, 0x8000000 - 0x800FFFF
- ERROR: RAM check failed # address 0x20000000.
- ERROR: Write: 0x03020100 07060504
- ERROR: Read: 0xAAAAAAAA AAAAAAAA
- ERROR: (0 bytes of RAM have been checked successfully)
- ERROR: Failed to read back target memory
Disconnecting ...
- Disconnected
I don't know how to use BOOT0 and BOOT1 to get into ISP mode. BOOT0 is connected to GND.
Post some information about your environment.
Are you using IAR EWARM? If you're not, you should download the size-limited trial version. Then, load one of the basic program examples, and try to flash it to your board.
What board are you using? And what do you mean you "closed" SWD and JTAG? I'm not sure what that refers to...jumpers? options window?
Help us out here.